cms-sw
move logic of HLT-Beamspot choice from `ESProducer` to `EDProducer`
During LS2, a new workflow has been introduced to produce the beamspot collection used in the HLT reconstruction (see, for example, this talk, although I'm sure there were many more).
This includes a ESProducer which chooses which BeamSpotObjects is used for a given IOV (with LS granularity); this step includes a check on the timestamp of the BS payloads, to avoid choosing ones that are older than a certain time threshold (normally set to 48h).
The issue is that the BS-payload timestamp is compared to the job's wall time. While this effectively works for online jobs, it means that, when re-running the HLT offline on old-enough data, one must bypass this check (changing timeThreshold from 48 to a large-enough number). If this is not done, offline HLT jobs on old-enough data might pick a different BS with respect to what was used online, leading to different physics outputs.
HLT normally uses "offline customisations" to its menus which take this into account (see here), but in general this need to customise the ESProducer offline can very easily be missed.
A solution could be to change the reference time from the job's wall time to the timestamp of the event or LS. IIuc, this could be done by moving the choice of the BS product from the current ESProducer to a EDProducer (possibly BeamSpotOnlineProducer).
This problem was discussed on Aug-31, 2022 in the cms-hlt e-group (thread: "Online Beam Spot producer falls back to DB value because the ESProducer returned a fake beamspot"), and in the Core-Sw channel of the O&C Mattermost team.
This issue is to keep track of it, and hopefully ensure improvements are explored in time for Run2023.
FYI: @cms-sw/hlt-l2 @fwyzard @silviodonato @francescobrivio @mmusich @gennai
A new Issue was created by @missirol Marino Missiroli.
@Dr15Jones, @perrotta, @dpiparo, @rappoccio, @makortel, @smuzaffar can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
New categories assigned: tracking-pog,reconstruction
@slava77,@mmusich,@mandrenguyen,@clacaputo you have been requested to review this Pull request/Issue and eventually sign? Thanks
Should this be closed after https://github.com/cms-sw/cmssw/pull/47378?
technically we'll know if everything works correctly in production only after the FirstCollisions menu is deployed for the 2025 900GeV run (2025A). I'd leave this open until then.
technically we'll know if everything works correctly in production only after the FirstCollisions menu is deployed for the 2025 900GeV run (2025A). I'd leave this open until then.
I think now we can safely say that things worked out as intended after the integration of https://github.com/cms-sw/cmssw/pull/47378.
@cms-sw/reconstruction-l2 @cms-sw/tracking-pog-l2 feel free to sign.
