[DO NOT MERGE] Single iteration Patatrack and LST in HLT

[VourMa]

PR description

This is a procModifier-based implementation of LST in HLT, based on top of CMSSW_14_1_0_pre7 + cms-sw#45117 + cms-sw#45508. The target branch has been adapted accordingly to be able to make a clear comparison.
It is an adaptation/improvement over #63, which becomes moot in terms of LST (also mkFit would need to be re-implemented with the usage of procModifiers from that PR).
It tries to reuse the trackingLST procModifier, and it introduces a new one, seedingLST, which may become also useful for the offline setup in the near future.

The PR is not meant to be merged, as it will have to be rebased to whichever CMSSW version LST gets integrated. However, the developments are fairly decoupled from the rest of the framework and the rest of the LST code, so this PR should already be good enough for people to take a look and comment on the implementation details.

In terms of performance, this is shown in the "Tests on LST Configurations - Baseline vs. Patatrack+Legacy-seeded LST in InitialStep" section of this presentation.

Instructions on how to run

cmsrel CMSSW_14_1_0_pre7
cd CMSSW_14_1_0_pre7/src
cmsenv
git cms-init
git cms-addpkg Configuration HLTrigger
git remote add SegLink [email protected]:SegmentLinking/cmssw.git
git fetch SegLink
git checkout CMSSW_14_1_0_pre7_LST_alpakaPatatrackInHLT_LSTInHLT_latest
scram b -j 16

# Rerun L1, needed because the HLT samples I am using are produced with 14_0_X
cmsDriver.py Phase2 -s L1,L1TrackTrigger \
--conditions auto:phase2_realistic_T33 \
--geometry Extended2026D110 \
--era Phase2C17I13M9 \
--eventcontent FEVTDEBUGHLT \
--datatier GEN-SIM-DIGI-RAW-MINIAOD \
--customise SLHCUpgradeSimulations/Configuration/aging.customise_aging_1000,Configuration/DataProcessing/Utils.addMonitoring,L1Trigger/Configuration/customisePhase2FEVTDEBUGHLT.customisePhase2FEVTDEBUGHLT,L1Trigger/Configuration/customisePhase2TTOn110.customisePhase2TTOn110 \
--filein /store/mc/Phase2Spring24DIGIRECOMiniAOD/TT_TuneCP5_14TeV-powheg-pythia8/GEN-SIM-DIGI-RAW-MINIAOD/PU200_AllTP_140X_mcRun4_realistic_v4-v1/2560000/11d1f6f0-5f03-421e-90c7-b5815197fc85.root \
--fileout file:output_Phase2_L1T.root \
--inputCommands="keep *, drop l1tPFJets_*_*_*, drop l1tTrackerMuons_l1tTkMuonsGmt*_*_HLT" \
--outputCommands="drop l1tTrackerMuons_l1tTkMuonsGmt*_*_HLT" \
--mc -n 100 --nThreads 1

# Rerun L1 emulator + HLT (needed for any sample)
# In terms of procModifiers:
#    None -> Legacy seeding, CKF building
#    alpaka -> Patatrack seeding
#    trackingLST -> LST building for the initialStep
#    seedingLST -> LST seeding for the hightPtTripletStep
cmsDriver.py Phase2 -s L1P2GT,HLT:75e33 --processName=HLTX \
--conditions auto:phase2_realistic_T33 \
--geometry Extended2026D110 \
--era Phase2C17I13M9 \
--eventcontent FEVTDEBUGHLT \
--customise SLHCUpgradeSimulations/Configuration/aging.customise_aging_1000 \
--filein file:output_Phase2_L1T.root \
--fileout file:Phase2_L1P2GT_HLT.root \
--inputCommands="keep *, drop *_hlt*_*_HLT, drop triggerTriggerFilterObjectWithRefs_l1t*_*_HLT" \
--outputCommands='keep *_*InitialStepTrack*LST*_*_*, keep *_*HighPtTripletStepTrack*_*_*' \
-n 100 --nThreads 10 \
--procModifiers alpaka,trackingLST,seedingLST

# procModifiers are important also for the validation step
# and should be consistent with the ones used above
cmsDriver.py DQM -s VALIDATION:hltMultiTrackValidation \
--conditions auto:phase2_realistic_T33 \
--geometry Extended2026D110 \
--era Phase2C17I13M9 \
--datatier DQMIO \
--eventcontent DQM \
--filein file:Phase2_L1P2GT_HLT.root \
--hltProcess HLTX \
--fileout DQM.root \
-n 100 --nThreads 10 --procModifiers alpaka,trackingLST,seedingLST

cmsDriver.py HARVEST -s HARVESTING:@trackingOnlyValidation+@trackingOnlyDQM+postProcessorHLTtrackingSequence \
--filein file:DQM.root \
--scenario pp \
--filetype DQM \
--conditions auto:phase2_realistic_T33 \
--mc -n 100

mv DQM_V0001_R000000001__Global__CMSSW_X_Y_Z__RECO.root configName.root
makeTrackValidationPlots.py configName.root --extended

[slava77]

what's the cost to the memory used from changes in this file?

[VourMa]

I am not sure.

In the final PR, these increase "only" by 10x (and I can probably fine-tune it to something less). They are also needed only in the case of seedingLST, which I would not use at this stage. Maybe I should not touch them and revisit if/when the seedingLST config becomes usable?

[slava77]

I'm partly confused what "final PR" means. Does it mean that at least this PR target branch should be updated or the PR itself to be rebased?

I think https://docs.google.com/spreadsheets/d/1-tDK4nIPlrB-0SoeEbnJlf_lyt-xTZcIhmZGRnR-fnY/edit?gid=16484832#gid=16484832 is still mostly up to date at least for memory per object. So, just the expected memory use would be enough to clarify my question.

[VourMa]

I'm partly confused what "final PR" means. Does it mean that at least this PR target branch should be updated or the PR itself to be rebased?

Also the PR needs to be rebased. Small adjustments but it needs to. The target branch will also change - should I just switch to SegmentLinking/master, after I sync it with the upstream, or will that cause issues?

I think https://docs.google.com/spreadsheets/d/1-tDK4nIPlrB-0SoeEbnJlf_lyt-xTZcIhmZGRnR-fnY/edit?gid=16484832#gid=16484832 is still mostly up to date at least for memory per object. So, just the expected memory use would be enough to clarify my question.

The spreadsheet was not up to date. I updated the default numbers and I get:

• size = 1208.8
• cache size = 1503.8

When using the values for the upcoming PR (the latter two 10x less than what is there in this PR):

n_max_pixel_segments_per_module = 500000;
n_max_pixel_track_candidates = 300000;
n_max_nonpixel_track_candidates = 10000;

I get:

• size = 1274.6
• cache size = 1581.1

I.e. ~5% increase in size and cache size. I will post the same numbers in PR description of the new PR.

[slava77]

The target branch will also change - should I just switch to SegmentLinking/master, after I sync it with the upstream, or will that cause issues?

master should be OK as a target, but please start the topic branch from some pre-release (pre4?) if possible. This way it should be easy to add it also to an LST development branch once we converge on the name and merge-base.

[VourMa]

Indeed, I started from CMSSW_14_2_0_pre4 (made it clear also in the branch name and the PR description).

[VourMa]

Closing this PR in favor of PR #132.