-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NGT] Implement new seeding module for HLT Standalone Muon seeding and streamline HLT L3 Tracker Muon reconstruction #46897
Conversation
cms-bot internal usage |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-46897/42945
|
A new Pull Request was created by @Parsifal-2045 for master. It involves the following packages:
@AdrianoDee, @Martin-Grunewald, @Moanwar, @antoniovagnerini, @antoniovilela, @cmsbuild, @davidlange6, @DickyChant, @fabiocos, @jfernan2, @mandrenguyen, @miquork, @mmusich, @rappoccio, @rseidita, @srimanob, @subirsarkar can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
test parameters:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are just cosmetic comments from a quick transversal look.
I'll go through the dense C++ changes in the coming days.
A general request for clarification.
What is the plan to re-absorb phase2L3MuonsOIFirst
and phase2L2AndL3Muons
process modifiers in the mainstream configuration?
The question is not really for the PR proponent but I have a feeling we're diverging with the options for the phase-2 menu. @rovere @VourMa
...Configuration/python/HLT_75e33/modules/hltIter2Phase2L3FromL1TkMuonPixelSeedsFiltered_cfi.py
Outdated
Show resolved
Hide resolved
...figuration/python/HLT_75e33/modules/hltPhase2L3FromL1TkMuonPixelTracksTrackingRegions_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonMerged_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonMerged_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonFilter_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonFilter_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonMerged_cfi.py
Outdated
Show resolved
Hide resolved
mat[1][1] = 0.05 * 0.05; // sigma^2(lambda) | ||
mat[2][2] = 0.2 * 0.2; // sigma^2(phi) | ||
mat[3][3] = 20. * 20.; // sigma^2(x_transverse) | ||
mat[4][4] = 20. * 20.; // sigma^2(y_transverse) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where are all these numbers coming from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The propagation to the various muon stations have remained basically unchanged from the current L2 MuonSeedGenerator (seeded by L1Tk Muons)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we consider storing these numbers in a single place for both modules? or is the old seed generator going to be discontinued?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The aim is for this new module to replace the current "legacy" seeding strategy. However, it's currently under a process modifier as a soft introduction while some slight inefficiencies are ironed out and its performance is assessed thoroughly. In any case, in the end, there should be a single Standalone Muon seed from L1Tk Muons generator
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonMerged_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonMerged_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3MuonMerged_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3OISeedsFromL2Muons_cfi.py
Outdated
Show resolved
Hide resolved
HLTrigger/Configuration/python/HLT_75e33/modules/hltPhase2L3OISeedsFromL2Muons_cfi.py
Outdated
Show resolved
Hide resolved
continue; | ||
} | ||
float eta = l1TkMuRef->phEta(); | ||
float theta = 2 * std::atan(std::exp(-eta)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this pattern together with the usage of ThreeVector
from CLHEP
smells.
What about something possibly more efficient reducing the usage of trig functions along the lines of 6272d52 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The latest commit should address this. It's still computing theta (only once per L1TkMu) since it's used for the stub-segment matching, but everything has been refactored to result in fewer overall "taxing" computations
- Takes full advantage of the Phase 2 L1 Tracker Muon information - Direct match between L1 stubs and segments in DTs/CSCs - Extract stubs from L1Tk Muon, only checks segments in the same chamber as the stub to match - Match based on dphi, dtheta and number of hits in the segment - In the barrel, if no match is found in a given station, a rough extrapolation is attempted from the closest station with a match - At most one seed per L1Tk Muon produced in a single seeding step, with the possibility to extend to exotic signatures
- execute either Inside-Out or Outside-In reconstruction first, resorting to the second pass only for candidates that require it - Tracks filtered by quality using some of the same criteria as HLT Muon ID - L1/L2 objects matched with bad L3 tracks are reused to seed the second reconstruction step - Changes implemented via 2 procModifiers for IO first (default) and OI first reconstruction - Implemented changes in SingleMu, TTbar, and ZMM workflows with .777 and .778 subfixes for IO and OI first reconstruction, respectively - Change 2026 to Run4 in Phase 2 workflows
a979b05
to
4762785
Compare
+1 Size: This PR adds an extra 28KB to repository
Comparison SummarySummary:
|
+1 |
+dqm
|
+pdmv |
@cms-sw/l1-l2 can you please take a look to the simple change in the list of keep statements of |
+l1 Looks fine from my end, thanks for catching the wrong "keep" statement because of the name change. |
This pull request is fully signed and it will be integrated in one of the next master IBs (tests are also fine). This pull request will now be reviewed by the release team before it's merged. @mandrenguyen, @sextonkennedy, @rappoccio, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This PR implements a new Standalone (L2) Muon seeding strategy that fully utilizes the L1 Tracker Muons (L1TkMu) information.
L3 Tracker Muon reconstruction is also streamlined, also taking advantage of the improved L1TkMu, to reduce redundancy.
The full scope of the changes was described in the HLT Upgrade meeting on 8/10/2024, while the details on the integration were presented in the meeting on 3/12/2024.
The new L2 seeder directly matches the stubs used to produce each L1TkMu with segments in DTs/CSCs. All matched segments are assigned to the seed, together with the pT measurement from the L1TkMu. This approach produces a single collection of seeds.
On the other hand, the current implementation produces two collections of seeds (from L1TkMu and "offline") that require matching and produces roughly a factor of 5 more seeds in ZMM simulated events with 200 PU.
The changes implemented in the seeding module results in a significant improvement in timing (about 42%) with mostly compatible efficiency.
The streamlining of the L3 reconstruction hinges on the idea of performing either the Inside-Out or the Outside-In L3 Tracker Muon reconstruction first, to then execute a second pass only for candidates that require it (i.e. either they were not reconstructed in the first pass or the quality of the track was not good enough). This approach starts from either reconstruction path (flexible in case of future changes or detectors' requirements) to produce a filtered collection of L3 tracks: the filter uses some of the same criteria used in the HLT Muon ID step (e.g. number of hits in the pixel, number of hits in the tracker, normalized chi2, ...). The filtered L3 Tracks are geometrically matched to either L1TkMu (Outside-In first) or Standalone Muons (Inside-Out first):
From the current results, the Inside-Out first approach seems to perform better, with more than 80% of the events in a ZMM sample at 200 PU requiring a single reconstruction path, to be compared with about 20% for the Outside-In first approach.
In any case, the streamlined L3 reconstruction reduces the fakerate in the merged (L3 IO + L3 OI) tracks collection as well as timing, while maintaining compatible physics perfomance until and including the final HLT Muon ID objects. All results, validation plots and ntuples are available here
The changes have been implemented using two new process modifiers:
These process modifiers have been included in a set of workflows targeting SingleMu, TTbar, and ZMM samples:
PR validation:
Validation builds on top of #46860 introducing specific validation paths for the new objects (e.g. filtered collections, objects to reuse). Physics performance mostly compatible with the current implementation. Tested on CMSSW_14_2_0_pre3 RelVals (TTbar and ZMM) (not pre4 due to those being limited to 35 PU) as well as private production with workflows 29834(.0, .777, .778) (TTbar) and 29850 (.0, .777, .778) (ZMM).
Please test on Phase 2 workflows using also .777 and .778 modifiers