Muon Inside -> Out reconstruction - Cure CPU footprint
Hi everybody,
this MR cures the sudden breakdown of the data processing caused by the Inside -> Out chain of muon reconstruction. Let me first explain, the very basic principles of MuGirl. If an existing MS segment is found in a particular sector of the MS, Inner Detector tracks are extrapolated through all stations of the spectrometer. The track parameters at each station are used to gather close-by hits in the MS and finally to seed a rebuilding of the segments. That's restoring efficiency if a particular chamber has too few hits, phi information is missing completely, or the traversing particle is actually a low-beta track, which would lead to disrupted drift-time spectra in the Mdts as the tier0 assumption no longer holds. Anyway, the latter can only be corrected in the barrel, where the RPCs deliver proper timing information.
The integration of the NSW into MuGirl is nothing else than a recall of the same segment maker as in the Outside -> In chain. In 22.0.99, we're bitten by two unfortunate circumstances and one mistake that unfortunately did not show up in the daily SPOT tests:
- Large occupancy of inner detector tracks in the endcaps
- An occupancy of around 20 clusters per micromega layer
Both of them let already the combinatoric explode in the first place. However, in !!57423 (merged) stereo seeding was rewritten such that only 2 out of 4 stereo layers in the NSW are required. I assumed that the seeding transformations are fast enough to cope with the combinatorics, which is not the case. Around 500k seeds were built per event.
To bring down the number of seeds the following changes are now implemented:
- The eta range cut in the IP constraint can be already applied at an earlier stage to each pair of parallel strips. Based on their separation in z, a cut on their radial separation is derived. 25% extra is taken as a safety margin
- Reject any seed containing more than 2 micromega clusters with only 1 strip
These 2 requirements already cure the CPU footprint of the MuGirl chain by a factor of 5. However, thinking more thoroughly the NSW segment building is pretty decoupled from the track parameters provided by the MuonInDetExtension. The same collection of hits is shown to the tool again and again for each track. If the Outside -> In chain was not able to compile a segment, why should it now happen out of a sudden? Let's recycle the MS segments from the previous step and not even try to build them again. The table below summarizes the CPU timing pre and post-fix using the test provided by @amete in ATLASRECTS-7343.
| before (total) [ms] | before (per event) [ms] | after (total) [ms] | after (per event) [ms] | |
|---|---|---|---|---|
| MuonSegmentMaker | 87930 | 176 | 60065 | 120 |
| MuonInDetToMuonSystemExtensionAlg | 121695 | 244 | 112583 | 226 |
| MuonInDetToMuonSystemExtensionAlg_LRT | 54512 | 109 | 49972 | 100 |
| MuGirl | 2803362 | 5618 | 83138 | 166 |
| MuGirl_LRT | 992249 | 1988 | 27280 | 55 |
Tests on a low-pt di muon sample have been submitted already to assess the physics impact at low pt.
Tagging: @elmsheus, @jcatmore, @nstyles, @amete, @christos, @mhodgkin, @jmaurer, @pberta, @strichte, @pscholer, @goblirsc, @sroe, @npetters, @nairz
Closes ATLASRECTS-7343
