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
Adding check to ensure L1Menu consistency in the HLT : 112X #31461
Adding check to ensure L1Menu consistency in the HLT : 112X #31461
Conversation
…menu as the L1 originally used
The code-checks are being triggered in jenkins. |
@Martin-Grunewald: FYI |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-31461/18366
|
A new Pull Request was created by @Sam-Harper (Sam Harper) for master. It involves the following packages: CondFormats/L1TObjects @benkrikler, @christopheralanwest, @tocheng, @cmsbuild, @rekovic, @tlampen, @ggovi, @pohsun can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins.
|
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Any comments from @cms-sw/alca-l2 @cms-sw/db-l2 @cms-sw/l1-l2 ? |
+alca |
Hi @cavana, thanks. You can also see https://hypernews.cern.ch/HyperNews/CMS/get/L1TriggerSW/869.html for more details. Its been bubbling along for a while (it got L1 TDRed and then covided leading to large delays) |
Hi @Sam-Harper, many thanks for this development and glad to hear that you are back to healthy -- I'm not sure which is worse, being TDRed or covided :-). I've quickly reviewed the PR and it looks good to me -- I'm happy to endorse it. Thanks for your patience as I try to come up to speed with all things uGT emulator. Best wishes, Rick |
Thanks. And for covid, I meant, it fell by the wayside of general covid chaos and disruption (it was being discussed in late march) and was forgotten about, not that I got covid! Thanks for endorsing it, this will greatly increase the robustness of the HLT |
The tests are being triggered in jenkins.
|
+1 |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
merge |
+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 be automatically merged. |
h ^= data[2] << 16; | ||
case 2: | ||
h ^= data[1] << 8; | ||
case 1: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Sam-Harper Is the purpose of case 3:
and case 2:
to fall through (i.e. is the break;
omitted on purpose)?
(spotted by gcc 9 warnings)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no idea. This is was copied from https://gitlab.cern.ch/cms-l1t-utm/utm/-/blob/master/tmUtil/tmUtil.cc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know who would know?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, @rekovic might know though. Here we are emulating firmware deployed at p5 though. So even if it is "buggy" its still correct I think as long as it agrees with the hardware output at p5.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@makortel @Sam-Harper , looks like the fall through is on purpose. I have opened a PR #31828 to silence GCC 9 warnings
PR description:
The L1 result is packed into the RAW data as 512 bits which each bit corresponding to a given L1 seed. Which seed corresponds to a given bit is determined by the L1 menu which is sent as conditions data. It is possible for the wrong L1 menu to be read if the corresponding entry in the global tag is incorrect. In this case the bits will not correspond to the L1 seeds the HLT thinks they do and thus when it thinks its requiring EG40 to pass, its really requiring Mu16 (as a hypothetical example).
This PR adds the function which can convert the the firmware uuid to the hash of the firmware uuid send in the RAW data along with the L1 results. This can be then checked by the L1 GT emulator (L1TGlobalProducer) to ensure that the correct menu is being re-emulated and throw an exception if not.
Note L1TGlobalProducer has two distinct use cases
It is use case 2) where we need to check that the menu we are emulating to create the l1 object map is the same as the menu used to create the L1 result in the RAW data. This is why this is an optional check (which will always be enabled in the HLT) as it doesnt make sense for use case 1)
Zero physics changes are expected.
PR validation:
runTheMatrix tests succeeded.
testing with the incorrect menu resulted in the exception being thrown