move per-run changes of L1-uGT emulator to beginRun (incl. loading of AXOL1TL model)
#47070
Conversation
…ditions Move per-run operations which are currently in L1TGlobalProducer::produce to L1TGlobalProducer::beginRun. In particular, the creation of the "trigger conditions" which is currently implemented in the method GlobalBoard::runGTL is moved to a separate method named GlobalBoard::initTriggerConditions, which is to be executed once per run (as opposed to GlobalBoard::runGTL, which is executed once per event).
|
cms-bot internal usage |
|
-code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-47070/43242 ERROR: Build errors found during clang-tidy run. |
| if (m_saveAXOScore and m_storedAXOScore < 0 and cond.first == m_axoScoreConditionName and | ||
| not m_axoScoreConditionName.empty()) { | ||
| auto const* theCondition = dynamic_cast<AXOL1TLCondition*>(cond.second.get()); | ||
| m_storedAXOScore = theCondition->getScore(); |
There was a problem hiding this comment.
Note: as far as I understand, since condMap is a std::unordered_map, the order of the iterations in the loop is not known a priori, so if the L1T menu contains multiple instances of AXOL1TLCondition using different models, the choice of the model for which the score is saved is not well-defined either. As discussed in cms-sw/cmssw#45227 (comment), the current implementation of this score-saving logic is anyway based on the assumption that the L1T menu uses only a single AXOL1TL model, so what is implemented in this PR is arguably no worse than what is in master.
(My 2 cents is that one should consider removing this score-saving logic from the emulator, and just produce these score values via a dedicated plugin.)
There was a problem hiding this comment.
(My 2 cents is that one should consider removing this score-saving logic from the emulator, and just produce these score values via a dedicated plugin.)
That was the very initial proposal, but in this case it is more difficult to map it to the version used in the L1 menu.
Do you have an idea whether one could read of the menu version in a producer upstream of the uGT emulator?
There was a problem hiding this comment.
As far as I understand, everything about the L1T menu is known from (or, can be built from the info in) the EventSetup (e.g. from info in the GlobalTag), so one can access this kind of info in any producer "upstream of the uGT emulator". The only input which is needed "upstream of the uGT emulator" is the L1T objects.
(That said, I don't know how hard it would be to write such a plugin; I would need to look more closely at the details.)
|
Changes to the emulator infrastructure have been merged in: cms-hls4ml/hls4mlEmulatorExtras#6 |
The corresponding |
|
code-checks with cms.week1.PR_3baa1e1e/100.0-69c825376e90e94baba247811053046b |
|
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-47070/43259
|
|
A new Pull Request was created by @missirol for master. It involves the following packages:
@aloeliger, @cmsbuild, @epalencia can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
|
Just saw that, FYI @quinnanm |
PR description:
This PR implements two improvements to the L1-uGT emulator. It goes in the direction of addressing #46740.
missirol@9dc135c moves several operations from
L1TGlobalProducer::producetoL1TGlobalProducer::beginRun(these are operations that depend only on the L1T trigger menu, which (afaik) may only change during run transitions). In particular, this leads to building the map of "trigger conditions" (instances of classes inhering fromConditionEvaluation, one of them beingAXOL1TLCondition) only once per run, as opposed to once per event.missirol@fe94271 moves the initialisation of the
hls4mlmodel inAXOL1TLConditionfrom itsevaluateConditionmethod (used multiple times per event) to its constructor (called only a few times per run given missirol@9dc135c).This PR requires cms-hls4ml/hls4mlEmulatorExtras#6, a simple improvement of the methods of the class
hls4mlEmulatorExtras::ModelLoaderin thehls4mlEmulatorExtrasexternal (this update is available via cms-sw/cmsdist#9606).(This PR will likely need to be rebased if #47030 is merged first.)
PR validation:
Validated in
CMSSW_15_0_0_pre1with the checks described in #46740 (comment).If this PR is a backport, please specify the original PR and why you need to backport that PR. If this PR will be backported, please specify to which release cycle the backport is meant for:
N/A