-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Integrate FED25 handling in electron online reconstruction #43555
Conversation
type egamma |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-43555/38156
|
A new Pull Request was created by @RSalvatico (Riccardo Salvatico) for master. It involves the following packages:
@cmsbuild, @mandrenguyen, @jfernan2 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-035d6a/36442/summary.html Comparison SummarySummary:
|
+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. @rappoccio, @sextonkennedy, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
out of curiosity, has this any measurable impact on the HLT timing? From the PR report looks like we're running the on demand Strip at HLT clustering more often with these changes (I guess because of more electron seeds?) |
Yes, it makes sense that there is some increase. I can measure the timing. |
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.
some unrequested (and un-necessary) feedback below.
Also somehow le
is a widespread shorthand in tracking code for local error, if the new variables were called lexx
and leyy
perhaps the code would be slightly less obfuscated.
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-43555/38177
|
Pull request #43555 was updated. @mandrenguyen, @jfernan2 can you please check and sign again. |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-035d6a/36464/summary.html Comparison SummarySummary:
|
@mmusich The impact of these changes on the HLT timing shouldn't be large (see attached plot). I've run it another time and saw a slightly larger difference (~2 ms increase rather than the 0.4 ms you see here), so I guess it's within uncertainties. |
thank you @RSalvatico |
+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. @sextonkennedy, @rappoccio, @antoniovilela (and backports should be raised in the release meeting by the corresponding L2) |
+1 |
+1 Summary: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-035d6a/36516/summary.html Comparison SummarySummary:
|
PR description:
This PR contains changes needed for the electron online reconstruction to be able to handle errors such as FED25 to flag malfunctioning Pixel modules. With respect to the current way of handling errors, which is maintained via the
isActive()
methodcmssw/RecoEgamma/EgammaElectronAlgos/src/TrajSeedMatcher.cc
Line 356 in 754d4fb
the new method allows us to catch cases where the flagging happens on a per-event basis (i.e., no need to mask those modules permanently via SiPixelQualityRcd).
In addition, if in the future a 2023 MC will be made where the FED25 error is used to simulate the BPIX issue (e.g., via a probability function), with these changes the online electron reconstruction code should be able to handle it correctly.
PR validation:
I observed an improvement in efficiency for electron triggers (such as HLT_Ele32_WPTight_Gsf) when running them with the proposed changes. The sample used for the test was a DY simulation where the issue in the faulty BPIX modules in layers 3 and 4 in 2023 was simulated at the level of the digitizer (i.e., the channels corresponding to the faulty modules produce an error FED25). Some plots can be found here. Please note that the efficiencies are calculated using gen-level electrons and basically no selection, so on an absolute scale they can look low.
The PR also passed some basic runTeMatrix tests.