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
Addition of histograms to the Muon DQM #22456
Conversation
… variables used by the soft MVA muon and occupancy plots for events with DCS flags set to BAD
@parbol, CMSSW_10_1_X branch is closed for direct updates. cms-bot is going to move this PR to master branch. |
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-22456/3730 |
A new Pull Request was created by @parbol for master. It involves the following packages: DQMOffline/Muon @vazzolini, @kmaeshima, @dmitrijus, @cmsbuild, @jfernan2, @vanbesien can you please review it and eventually sign? Thanks. cms-bot commands are listed here |
please test |
The tests are being triggered in jenkins. |
-1 Tested at: c48201b You can see the results of the tests here: I found follow errors while testing this PR Failed tests: RelVals
When I ran the RelVals I found an error in the following worklfows: runTheMatrix-results/140.53_RunHI2011+RunHI2011+RECOHID11+HARVESTDHI/step2_RunHI2011+RunHI2011+RECOHID11+HARVESTDHI.log150.0 step3 runTheMatrix-results/150.0_HydjetQ_B12_5020GeV_2018+HydjetQ_B12_5020GeV_2018+DIGIHI2018+RECOHI2018+HARVESTHI2018/step3_HydjetQ_B12_5020GeV_2018+HydjetQ_B12_5020GeV_2018+DIGIHI2018+RECOHI2018+HARVESTHI2018.log |
Comparison not run due to runTheMatrix errors (RelVals and Igprof tests were also skipped) |
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) |
+1 adding ~ 78 kB of histograms, not negligible but still manageable IMO diff on dqmMemoryStats.py output for wf 10824.0 < 2564.04 KiB Muons_miniAOD/MuonRecoAnalyzer
|
@@ -264,6 +270,9 @@ void EfficiencyAnalyzer::analyze(const edm::Event & iEvent,const edm::EventSetup | |||
h_allProbes_pt->Fill(muon2->pt()); | |||
h_allProbes_eta->Fill(muon2->eta()); | |||
h_allProbes_phi->Fill(muon2->phi()); | |||
h_allProbes_inner_pt->Fill(muon2->innerTrack()->innerMomentum().Rho()); | |||
h_allProbes_inner_eta->Fill(muon2->innerTrack()->innerPosition().Eta()); | |||
h_allProbes_inner_phi->Fill(muon2->innerTrack()->innerPosition().Phi()); |
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.
These changes have broken DQM for miniAOD jobs running separately from AOD inputs.
E.g. in workflow 136.7611 running on 1000 events
[0] Processing Event run: 277069 lumi: 81 event: 35893405 stream: 0
[1] Calling method for module EfficiencyAnalyzer/'LooseMuonEfficiencyAnalyzer_miniAOD'
Exception Message:
RefCore: A request to resolve a reference to a product of type 'std::vector<reco::TrackExtra>' with ProductID '2:3025'
can not be satisfied because the product cannot be found.
Probably the branch containing the product is not stored in the input file.
@fabozzi
did we notice the problems already in relvals? Or are we not running these regularly?
jenkins tests will likely miss this problem because it takes 2 muons somewhat consistent with Z->mumu to make it to this problematic part of the code
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.
@slava77
there workflows are only tested in IB to maintain the sequence, we do not produce them in the relval set for regular validation campaigns
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 see. So, there are no relvals which run only miniAOD with DQM included?
How are you planning to test the reminiAOD of 2016?
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.
Sorry for the late reply. I've been absent the whole weekend. So, if I understand correctly, these jobs are failing when asking for the innerTrack to the Muons in miniAOD jobs. I guess this is because the innerTrack is not there anymore and the reference it's not valid. I have added a "IsminiAOD" boolean in such a way that this operation is not done when we are running a miniAOD workflow. However I am unsure how to test this new code is working. Is it enough to run it over a miniAOD file? Any suggestion? Thanks a lot.
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.
Don't we store the inner track inside pat::Muon? Just use pat::Muon::track() call instead. It will check if the track is embedded and if not, it will call innerTrack() method.
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.
Don't we store the inner track inside pat::Muon? Just use pat::Muon::track() call instead. It will check if the track is embedded and if not, it will call innerTrack() method.
Only the track is saved, not its TrackExtra.
The TrackExtra is not available in AOD
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 have added a "IsminiAOD" boolean in such a way that this operation is not done when we are running a miniAOD workflow.
good
However I am unsure how to test this new code is working. Is it enough to run it over a miniAOD file? Any suggestion?
In case 2017 AOD is at hand, I suggest to start from the matrix workflow 1325.51 and substitute the ttbar inputs with a Z->mumu AOD file.
The cmsDriver command with 1K events in the test is
cmsDriver.py step2 --conditions auto:phase1_2017_realistic -s PAT,VALIDATION:@miniAODValidation,DQM:@miniAODDQM --process PAT --era Run2_2017,run2_miniAOD_94XFall17 --eventcontent MINIAODSIM,DQM --runUnscheduled --scenario pp --datatier MINIAODSIM,DQMIO --mc -n 1000 --filein filelist:step1_dasquery.log --fileout file:step2.root
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 see why DQM would care about parameters at the inner point vs at point of closest approach, which is stored in Track. Also, it gets eta and phi of the inner point. Is it really what is needed? @parbol can you please clarify?
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 was an attempt to have in the DQM variables that might be sensitive to the pixels problem. Probably the same thing can be seen using the point of closest approach (what do you think Dima?), since everything we want to see is some degradation. I'm fine with both solutions: the IsminiAOD switch (already implemented), or changing to the point of closest approach.
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.
If it's to understand how deeply the track is going, don't you want then rho of the inner point, instead of momentum? I would expect that direction is good enough from POCA. Only location of the first hit can be interesting. Guys, what do you think?
@fabiocos |
@slava77 let me follow-up in a separate issue |
if (&(*beamSpot)==NULL) { | ||
refPoint = beamSpot->position(); | ||
} else { | ||
cout << "ERROR: No beam sport found!" << endl; |
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 message is appearing e.g. in 20034.0 step3 logs (phase2 workflow). cout
should not be used.
Also, I'm not sure I understand the logic that you try to assign the refPoint
only if the beamSpot
address is null...
Hello, I have made a new branch correcting the issues before: https://github.com/parbol/cmssw/tree/DQMMuonDCSFlag_v2 In particular it corrects three things:
Please, could you let me know to which CMSSW should I send the PR against? CMSSW_10_1_X, 2_X? Thanks |
Please make the PR to master branch, which currently corresponds to 10_2_X. You will need to rebase your branch (which is currently based on 10_1_X). It would also be nice to fix the typo "sport" -> "spot" in the printout. I leave it up to the DQM reviewers to decide if it should be backported. |
Ok, it's done in: Thanks |
In this pull request I'm adding histograms to the Muon DQM in order to correct/improve three aspects:
Two Monitor Elements per Muon ID have been added in EfficiencyAnalyzer.cc and EfficiencyPlotter.cc showing the efficiency as a function of the phi and eta of the innermost hit of the innertrack of the muon.
One Monitor Element per Muon ID (Loose, Medium, Tight) has been added to DiMuonAnalyzer.cc to monitor the ratio between the number of bad hits and good hits in the inner track for events where the two leptons have a mass compatible with the Z mass.