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
Make ElectronMVA usable in FWlite again #25337
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-25337/7360 |
A new Pull Request was created by @guitargeek (Jonas Rembser) for master. It involves the following packages: DQMOffline/Lumi @perrotta, @andrius-k, @kmaeshima, @schneiml, @monttj, @cmsbuild, @jfernan2, @fgolf, @slava77, @peruzzim can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
@guitargeek , thank you for this, really appreciate it! |
Hi all, I really appreciate this as well, and I would like to thank again @guitargeek very much for all the work. Just one thing though, there are a couple very small developments missing before we can apply the mva ID in FWLite. I did a PR to @guitargeek for that (https://github.com/guitargeek/cmssw/pull/1) and we will need to add these developments here (or in a later PR) when we're done. |
+1 The following merge commits were also included on top of IB + this PR after doing git cms-merge-topic: |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
Comparison job queued. |
Comparison is ready Comparison Summary:
|
I quickly glanced at the timing performance of the new code. With the TTbar PU workflow 25202 I could verify that there is indeed also evidence of some little optimization with this code, although the modules involved were not large CPU consumers even before:
|
+1
|
+1 |
+1 the fwlite test provided runs smoothly |
+xpog for the modification to |
Hi,
in the discussion about issue #23676 it became evident that the current electron MVA ID does not work in FWlite/Python. Mainly the reason for this was that the MVA classes have to get additional variables not in the objects from edm::ValueMaps and the objects therefore need to be wrapped in something Ref-like (
edm::Ptr
s in the current implementation).To get around this, we propose to add another helper class (
MVAVariableHelper
) to the Egamma MVA framework which calculates the extra variables and passes is to the MVA classes, which in turn don't need any other event or provenance information no more. The same function used by the new MVAVariableHelper to get the extra electron variables can also used in FWLite. An example will be included in the test code. There is also a new Python wrapper class which makes using the most recent Electron MVAs for 2016 and 2017 in Python very easy.Furthermore, I cleaned up the MVANtuplizers a bit and more importantly changed the interface of the ConversionTools to not require edm::Handles anymore. Which makes their usage a bit more consistent in FWlite/Python with the other code I wrote.
Local matrix tests pass and I checked the output of the new fwlite test and the ElectronMVANtuplizer for numerical agreement of MVA values. Validation plots here [1]. If one wants to reproduce the comparison, the pt threshold in the ElectronMVANtuplizer has to be set to zero [2] and one could make the comparison plots with this script for example.
I hope everyone is fine with these changes and I don't have to touch the MVA code again any time soon.
Cheers,
Jonas
Shout-out to who discussed in the issue-thread @Dr15Jones, @makortel and of course to @cbernet for the nice discussion and help but in particular the FWlite example!
[1] https://rembserj.web.cern.ch/rembserj/plots/CMSSW_PRs/25337/
[2] https://github.com/cms-sw/cmssw/blob/master/RecoEgamma/ElectronIdentification/plugins/ElectronMVANtuplizer.cc#L424
[3] https://gitlab.cern.ch/snippets/636