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
[muon] a workaround for enum to int conversion problem in pyROOT #26446
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26446/9250
|
A new Pull Request was created by @drkovalskyi for master. It involves the following packages: DataFormats/PatCandidates @perrotta, @cmsbuild, @santocch, @slava77 can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
@cmsbuild please test |
The tests are being triggered in jenkins. |
@folguera |
No, the sim-hit matching problem is still not understood. It's a different bug/problem/feature. |
Comparison job queued. |
Comparison is ready Comparison Summary:
|
/// returns reco::MuonSimType - we cast it to int to avoid issues in pyROOT | ||
int simType() const { return simType_; } | ||
/// reco::ExtendedMuonSimType - we cast it to int to avoid issues in pyROOT | ||
int simExtType() const { return simExtType_; } |
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.
This solution degrades type safety to serve a broken external use case.
I propose to introduce/add simTypeInt
and simExtTypeInt
with appropriate comments that it's to be used in FWLite environment where the scoped enums are not properly recognized.
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.
I don't think your solution will work well because the user needs to know that he has to use simTypeInt to be safe. I have personally rediscovered this problem 3 times, i.e. one tends to forget about it and use it as is. All these accessors are primarily used by endusers, i.e. there won't be many use cases where someone would really benefit from type safety. In other words the tradeoff is between a benefit that won't be used vs a real problem that affects a number of users.
please share the ROOT JIRA issue number for this. |
The tests are being triggered in jenkins. |
Comparison job queued. |
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
I tested a slightly modified version in CMSSW_11_0_ROOT6_X_2019-09-03-0600 #!/bin/env python
import os, re, sys, time, ROOT, subprocess
from DataFormats.FWLite import Events, Handle
muonHandle, muonLabel = Handle("std::vector<pat::Muon>"),"slimmedMuons"
ROOT.gROOT.SetBatch(True)
events = Events("root://cms-xrd-global.cern.ch//store/group/phys_muon/dmytro/tmp/store+mc+RunIIAutumn18MiniAOD+DYJetsToLL_M-50_TuneCP5_13TeV-madgraphMLM-pythia8+MINIAODSIM+102X_upgrade2018_realistic_v15-v1+80000+695EE995-7CA9-5A46-81EF-C6777A74C791.root")
nevents = 0
print "ROOT.reco.MatchedMuonFromGaugeOrHiggsBoson = ", ROOT.reco.MatchedMuonFromGaugeOrHiggsBoson
print "ROOT.reco.GhostMuonFromGaugeOrHiggsBoson = ", ROOT.reco.GhostMuonFromGaugeOrHiggsBoson
print "ROOT.reco.ExtendedMuonSimType.GhostMuonFromGaugeOrHiggsBoson = ", ROOT.reco.ExtendedMuonSimType.GhostMuonFromGaugeOrHiggsBoson
for event in events:
if nevents>=100: break
nevents+=1
event.getByLabel(muonLabel, muonHandle)
muons = muonHandle.product()
for muon in muons:
if muon.simExtType()==ROOT.reco.GhostMuonFromGaugeOrHiggsBoson or muon.simExtType()>1e4 or muon.simExtType()<0:
print "simExtType()==ROOT.reco.GhostMuonFromGaugeOrHiggsBoson or pos/neg: pt: %0.1f \tsimType: %d \textSimType: %d" % (muon.pt(),muon.simType(),muon.simExtType())
if muon.simExtType()==ROOT.reco.GhostMuonFromGaugeOrHiggsBoson:
print "simExtType()==ROOT.reco.GhostMuonFromGaugeOrHiggsBoson: pt: %0.1f \tsimType: %d \textSimType: %d" % (muon.pt(),muon.simType(),muon.simExtType())
if muon.simExtType()==ROOT.reco.ExtendedMuonSimType.GhostMuonFromGaugeOrHiggsBoson:
print "simExtType()==ROOT.reco.ExtendedMuonSimType.GhostMuonFromGaugeOrHiggsBoson: pt: %0.1f \tsimType: %d \textSimType: %d" % (muon.pt(),muon.simType(),muon.simExtType()) The output now seems to make sense:
this also apparently works in root 6.18 branch e.g. in CMSSW_11_0_ROOT618_X_2019-09-03-0600 @drkovalskyi |
@drkovalskyi |
It all looks good in my tests. |
-1 this is no longer necessary after the root update available starting from see notes in cms-sw/cmsdist#5321 (comment) @drkovalskyi |
@drkovalskyi I would say that this PR can be closed at this point, please comment in case, otherwise I'll clean this from the list. |
hold |
Pull request has been put on hold by @fabiocos |
@drkovalskyi thanks |
There is a subtle problem with python type conversion from signed enums to basic types. In some cases it converts negative enums to an unsigned int. For example instead of -10 you get 4294967286. This problem was report to ROOT team, but it was never fixed.
It's very easy to miss this problem and unfortunately one cannot rely on enum checks to avoid it, since for example ROOT.reco.GhostMuonFromGaugeOrHiggsBoson evaluates to -10 as it should, but simExtType() returns 4294967286.
The current workaround is documented on Muon POG twiki, but it's not a reliable solution. People (including me keep rediscovering this problem).
https://twiki.cern.ch/twiki/bin/view/CMS/SWGuideMuonIdRun2#SimHit_Muon_matching_since_CMSSW
The pull request provides a trivial fix - return int instead of the enum. I know it's ugly, but getting wrong physics results is worse.