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
Fixing Default Values of EgammaHLTGsfTrackVarProducer to be only used if there is a track found : 102X #22987
Fixing Default Values of EgammaHLTGsfTrackVarProducer to be only used if there is a track found : 102X #22987
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-22987/4374 |
A new Pull Request was created by @Sam-Harper for master. It involves the following packages: RecoEgamma/EgammaHLTProducers @Martin-Grunewald, @silviodonato, @cmsbuild, @fwyzard 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:
|
+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) |
type bugfix |
+1 |
Dear All,
First appologies for this bug, I didnt catch it in my testing which was only apparent on MuEG events due to how the DZ filters work differently for those paths.
When setting the default values for a track, we didnt check if a track was actually found. So even if there was no GsfTrack, good "auto" pass values were written. This unfortunately causes the mu-electron DZ filters to crash they dont check they actually find an electron.
This fix makes the default values only be written if the electron actually has a track. So no trackless electrons can now pass through to the DZ filters.
Best,
Sam