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
Redefine (in)valid GEM digis and pads #28335
Redefine (in)valid GEM digis and pads #28335
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-28335/12598
|
A new Pull Request was created by @dildick (Sven Dildick) for master. It involves the following packages: DataFormats/GEMDigi @cmsbuild, @civanch, @kpedro88, @mdhildreth can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
+upgrade |
+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, @slava77, @smuzaffar, @fabiocos (and backports should be raised in the release meeting by the corresponding L2) |
@dildick are we sure this does not interfere with existing datasets? I mean that these values cannot be assumed by old good data, and therefore their state of being good is unchanged? |
@fabiocos Correct. GEM BX value is 0 for in-time hits, while the GEM strip number is maximum 768. |
+1 |
PR description:
PR #24356 reset the begin pad as 0 instead of 1. This broke a function in the GEM-CSC trigger. To fix it, I redefine when strips, pads and clusters are valid. Default strips/pads are now initialized with bx -99 and strip/pad number 2^16-1.
PR validation:
I checked that it runs with WF 22034.
if this PR is a backport please specify the original PR:
N/A