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
PFRecHit navigator for HCAL with dense index #29049
PFRecHit navigator for HCAL with dense index #29049
Conversation
…ginRun. Use the PFRecHitHCALCachedNavigator for PFRecHitProducer of HBHE/HF/HO.
…ginRun. Use the PFRecHitHCALCachedNavigator for PFRecHitProducer of HBHE/HF/HO.
The code-checks are being triggered in jenkins. |
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-29049/13915
Code check has found code style and quality issues which could be resolved by applying following patch(s)
|
Thank you @perrotta . I think I incorporated your suggestions. Some further possible cleanup of time-related parameters may be deferred to another PR, as you say. |
please test |
The tests are being triggered in jenkins. |
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
I've reformatted the FastReport lines to be more readable: Before
With this PR
|
Thx! I propagated the reformat to the PR description. |
In the initialization of the HCAL navigator a vector of vectors (dimension I have evaluated with IgProf the live memory allocated for such an initialization, in the Phase2 wf 21234.0 (TTbar_14TeV+TTbar_14TeV_TuneCP5_2026D44), which including HGCal should represent a "worst case scenario" for it. IgProf says that 1 MB of memory will be allocated to store the
I've also compared the CPU timing in that wf with and without this PR: in my comparison no significant difference is visible in the reco step. However, that was done with an extremely limited sample (10 evts). For a larger stat, I rather keep the timing measurement reported in the PR description for HLT. By the way, @hatakeyamak , do you also have a comparison for the timing in offline reco? |
@perrotta I added the offline timing test in the PR description as well. The difference is visible when we are running on PU samples in which rechit multiplicity is larger. |
+1
|
Thank you @perrotta. I should have made it clear: this PR won't affect the navigator for HGCAL, and it speeds up only for HCAL. |
+1 |
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. @davidlange6, @silviodonato, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
PR description:
This is an update for PFRecHit navigator for HCAL using a vector of neighbor information filled with HCAL dense index. This is expected to cut down the PFRecHitProducer for HCAL by 30-40%.
Using HLT's OnLine_HLT_GRun.py on:
/eos/cms/store/data/Run2018D/EphemeralHLTPhysics5/RAW/v1/000/324/897/00000/F5F13777-D664-C747-88AA-0459C1E35254.root
(1000 events)
Offline setup
Also, we used this opportunity to clean up the unused module (PFCTRecHitProducer), clean up unused config parameters, and some of the initialization related to topology was moved from event-level to beginLuminosityBlock for efficiency.
PR validation:
Run validation based on a few matrix tests (ttbar for 2018 and 2021) and HLT test based on 2018 data (originally from):
https://fwyzard.web.cern.ch/fwyzard/patatrack/hlt_paths/original.py
and checked that PF candidate outputs are identical.
if this PR is a backport please specify the original PR and why you need to backport that PR:
This is not backport.
@bendavid @jsalfeld @mariadalfonso @bsunanda @abdoulline