Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

drkovalskyi
Copy link
Contributor

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.

@cmsbuild
Copy link
Contributor

The code-checks are being triggered in jenkins.

@cmsbuild
Copy link
Contributor

+code-checks

Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26446/9250

  • This PR adds an extra 20KB to repository

@cmsbuild
Copy link
Contributor

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.
@gpetruc, @cbernet, @gouskos, @rovere, @hatakeyamak this is something you requested to watch as well.
@davidlange6, @slava77, @fabiocos you are the release manager for this.

cms-bot commands are listed here

@slava77
Copy link
Contributor

slava77 commented Apr 12, 2019

@cmsbuild please test

@cmsbuild
Copy link
Contributor

cmsbuild commented Apr 12, 2019

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/34179/console Started: 2019/04/12 16:30

@drkovalskyi
Copy link
Contributor Author

FYI @bmahakud, @folguera

@slava77
Copy link
Contributor

slava77 commented Apr 12, 2019

@folguera
is this the fix in sim matching that you mentioned yesterday or is this something else?

@drkovalskyi
Copy link
Contributor Author

No, the sim-hit matching problem is still not understood. It's a different bug/problem/feature.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

Comparison job queued.

@cmsbuild
Copy link
Contributor

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-26446/34179/summary.html

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 32
  • DQMHistoTests: Total histograms compared: 3140495
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 3140297
  • DQMHistoTests: Total skipped: 197
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 31 files compared)
  • Checked 133 log files, 14 edm output root files, 32 DQM output files

/// 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_; }
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@slava77
Copy link
Contributor

slava77 commented Apr 13, 2019

This problem was report to ROOT team, but it was never fixed.

please share the ROOT JIRA issue number for this.

@cmsbuild
Copy link
Contributor

cmsbuild commented Aug 5, 2019

The tests are being triggered in jenkins.
Tested with other pull request(s) cms-sw/cmsdist#5130
https://cmssdt.cern.ch/jenkins/job/ib-run-pr-tests/1829/console Started: 2019/08/05 11:32

@cmsbuild
Copy link
Contributor

cmsbuild commented Aug 6, 2019

@cmsbuild
Copy link
Contributor

cmsbuild commented Aug 6, 2019

Comparison job queued.

@cmsbuild
Copy link
Contributor

cmsbuild commented Aug 6, 2019

Comparison is ready
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/PR-dd81cd/1829/summary.html

@slava77 comparisons for the following workflows were not done due to missing matrix map:

  • /build/cmsbld/jenkins/workspace/compare-root-files-short-matrix/results/JR-comparison/PR-dd81cd/11634.0_TTbar_14TeV+TTbar_14TeV_TuneCUETP8M1_2021_GenSimFull+DigiFull_2021+RecoFull_2021+HARVESTFull_2021+ALCAFull_2021

Comparison Summary:

  • No significant changes to the logs found
  • Reco comparison results: 0 differences found in the comparisons
  • DQMHistoTests: Total files compared: 33
  • DQMHistoTests: Total histograms compared: 2715989
  • DQMHistoTests: Total failures: 1
  • DQMHistoTests: Total nulls: 0
  • DQMHistoTests: Total successes: 2715659
  • DQMHistoTests: Total skipped: 329
  • DQMHistoTests: Total Missing objects: 0
  • DQMHistoSizes: Histogram memory added: 0.0 KiB( 32 files compared)
  • Checked 137 log files, 14 edm output root files, 33 DQM output files

@slava77
Copy link
Contributor

slava77 commented Sep 3, 2019

Here is a simple example: /afs/cern.ch/user/d/dmytro/public/forSlava/test_pyroot.py
When it works right you should get simType to be -10, when it's not you get 4294967294.
It reads data available at CERN, so it's better to run from CERN.

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:

ROOT.reco.MatchedMuonFromGaugeOrHiggsBoson  =  10
ROOT.reco.GhostMuonFromGaugeOrHiggsBoson  =  -10
ROOT.reco.ExtendedMuonSimType.GhostMuonFromGaugeOrHiggsBoson  =  -10
simExtType()==ROOT.reco.GhostMuonFromGaugeOrHiggsBoson or pos/neg: pt: 1.1      simType: -4     extSimType: -10
simExtType()==ROOT.reco.GhostMuonFromGaugeOrHiggsBoson: pt: 1.1         simType: -4     extSimType: -10
simExtType()==ROOT.reco.ExtendedMuonSimType.GhostMuonFromGaugeOrHiggsBoson: pt: 1.1     simType: -4     extSimType: -10
simExtType()==ROOT.reco.GhostMuonFromGaugeOrHiggsBoson or pos/neg: pt: 1.0      simType: -2     extSimType: -4

this also apparently works in root 6.18 branch e.g. in CMSSW_11_0_ROOT618_X_2019-09-03-0600

@drkovalskyi
please double-check that the issue is solved (either in CMSSW_11_0_ROOT618_X_2019-09-03-0600 or in CMSSW_11_0_ROOT6_X_2019-09-03-0600).
Thank you.

@slava77
Copy link
Contributor

slava77 commented Sep 6, 2019

#26446 (comment)

@drkovalskyi
please double-check that the issue is solved (either in CMSSW_11_0_ROOT618_X_2019-09-03-0600 or in CMSSW_11_0_ROOT6_X_2019-09-03-0600).
Thank you.

@drkovalskyi
please let me know if you had a chance to check.
Thank you.

@drkovalskyi
Copy link
Contributor Author

It all looks good in my tests.

@slava77
Copy link
Contributor

slava77 commented Nov 1, 2019

-1

this is no longer necessary after the root update available starting from
CMSSW_11_0_X_2019-10-31-2300

see notes in cms-sw/cmsdist#5321 (comment)
I also requested a backport of the root update for 10_6_X so that we have it in the long term support release

@drkovalskyi
please close this PR if you are fine with the resolution.

@fabiocos
Copy link
Contributor

fabiocos commented Dec 4, 2019

@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.

@cmsbuild cmsbuild modified the milestones: CMSSW_11_1_X, CMSSW_11_0_X Dec 10, 2019
@fabiocos
Copy link
Contributor

hold

@cmsbuild
Copy link
Contributor

Pull request has been put on hold by @fabiocos
They need to issue an unhold command to remove the hold state or L1 can unhold it for all

@fabiocos
Copy link
Contributor

@drkovalskyi thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants