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 ECAL-Trk energy combination such that it gets the uncorrected ecal energy err #23677
Fixing ECAL-Trk energy combination such that it gets the uncorrected ecal energy err #23677
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-23677/5335 |
A new Pull Request was created by @Sam-Harper (Sam Harper) for master. It involves the following packages: RecoEgamma/EgammaTools @perrotta, @cmsbuild, @slava77 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:
|
for the backport, please make it such that it is enabled only for the run2_miniAOD_80XLegacy. The alternative is to not do any changes in 94X but request an analysis release so that the fix can be applied on the fly. In this case, it will not be a part of the re-miniAOD. |
+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) |
+1 |
Dear All,
A flaw in how the ECAL-Trk combination is done has been reported to E/gamma which introduces a discontinuity in the Et spectrum when scaled & smeared. This is due to using the corrected relative ecalEnergyErr for the ECAL-Trk combination. This bug fix now means that the uncorrected relative ecalEnergyErr is used.
In scale and smearing, the smearing is applied in quadrature to correct ecalEnergyErr which represents the per electron estimate of the resolution. However due to how the combination uses this value, this results in incorrect responses. Details can be seen in https://indico.cern.ch/event/716848/contributions/3042888/attachments/1669765/2678161/scaleSmearingAndEP.pdf and a follow up https://sharper.web.cern.ch/sharper/cms/talks/scaleAndSmearingReprise.pdf
This bug effects the values stored in the 2017 miniAODv2 and the 2016 legacy miniAODv2. Obviously it is too late for the 2017 miniAODv2 but if it could fix the legacy, that would be good. These fixes can be applied at the user level, which will have to be done for 2017 data.
When backporting to 94X, will I need a flag in the module config to reproduce the original bugged version?