Add TRT corrections to the track overlay workflow
This merge request introduces a technique to incorporate TRT corrections (24.0 TRT HT tune, here) into the track overlay workflow. Traditionally, TRT corrections haven't been applied in the track overlay workflow because both signal and pileup RDOs are not read simultaneously. Following a suggestion from @beddall, this update implements a trick to apply TRT corrections within the workflow.
Physics validation impact:
- The m(yy) plots on slide 12 indicates the need for TRT corrections in the track overlay, here (plots were produced by @dduda)
- Some other key variables such as TRT HT hits and associated quantities like eProbability_HT can be found: After applying TRT corrections: https://fatsai.web.cern.ch/TrackOverlay/Run3HyyTRTCorr/?rid=r_617 Before applying TRT corrections: https://fatsai.web.cern.ch/TrackOverlay/Run3HyyNOTRTCorr/?rid=r_617
CPU performance: Adding additional Sig_TRTCorr_RDOs has very little or no impact for CPU performance, as detailed in recent CPU benchmarking results: here.
Updates plots after CI fix:
eProbability_HT and more https://fatsai.web.cern.ch/TrackOverlay/Run3HyyTRTCorr_config2/?rid=r_597
CPU performance (1000 events local test, 64 threads) Track overlay (red, monitored)
Overlay: 4289 [ms/event]
RAWtoALL:4395 [ms/event] (Hybrid: 994/1000 events are sent to the track overlay)
MC overlay (blue, reference)
Overlay: 4360 [ms/event]
RAWtoALL: 11869 [ms/event]
More updates (copied the main discussions below to the description) Two tests in the track overlay workflow when turning off backtracking for pileup tracks for 1000 events, and:
- Processing regular TRT_RDOs: recoPhotonConvLoose_convRadius, CPU: 3048 [ms]/event
- Processing Sig_TRTCorr_RDOs: recoPhotonConvLoose_convRadius, CPU: 3003 [ms]/event
We think it may make more sense to discard this MR, and process regular TRT_RDOs. Then we turn off the back tracking when producing pileup tracks.