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
Adding digi-based shower tagging to reco::Muon #26369
Adding digi-based shower tagging to reco::Muon #26369
Conversation
The code-checks are being triggered in jenkins. |
+code-checks Logs: https://cmssdt.cern.ch/SDT/code-checks/cms-sw-PR-26369/9108
|
A new Pull Request was created by @battibass (Carlo Battilana) for master. It involves the following packages: DataFormats/MuonReco @cmsbuild, @perrotta, @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. |
-1 Tested at: 4ad4961 You can see the results of the tests here: I found follow errors while testing this PR Failed tests: UnitTests RelVals
I found errors in the following unit tests: ---> test testTauEmbeddingProducers had ERRORS
When I ran the RelVals I found an error in the following workflows: runTheMatrix-results/101.0_SingleElectronE120EHCAL+SingleElectronE120EHCAL/step1_SingleElectronE120EHCAL+SingleElectronE120EHCAL.log |
Comparison not run due to runTheMatrix errors (RelVals and Igprof tests were also skipped) |
please test |
The tests are being triggered in jenkins. |
The tests are being triggered in jenkins. |
@davidlange6 the point is that I do not see any failure in the report, let's try it again... |
@slava77 now I see your question, only "abort" or "please abort" should do. from time to time we have this github webhook failures and that might be it, but I'll assume the bot got confused from your command |
@fabiocos I'm searching in the logs and it says
which in fact is not true, there are no test failing.
that sets the TEST_ERRORS to true doesn't make any sense, greps for any error, there is none, yet still returns true. lets see if it persists. |
Comparison job queued. |
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
Comparison Summary:
|
@civanch given the latest changes I will take your previous signature as valid, anyway please check and sign it again for future reference, or comment in case |
+1 |
merge |
ShowerDigiFillerParameters = cms.PSet( | ||
digiMaxDistanceX = cms.double(25.0), | ||
dtDigiCollectionLabel = cms.InputTag("muonDTDigis"), | ||
cscDigiCollectionLabel = cms.InputTag("muonCSCDigis","MuonCSCStripDigi") |
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.
@battibass @slava77 it looks like this line is creating issues in wf 1102.0 step4 RECOFROMRECO:
[7] Prefetching for module TrackProducer/'mergedDuplicateTracks'
[8] Prefetching for module DuplicateTrackMerger/'duplicateTrackCandidates'
[9] Prefetching for module TrackCollectionMerger/'preDuplicateMergingGeneralTracks'
[10] Prefetching for module TrackProducer/'muonSeededTracksInOut'
[11] Prefetching for module CkfTrackCandidateMaker/'muonSeededTrackCandidatesInOut'
[12] Prefetching for module MuonReSeeder/'muonSeededSeedsInOut'
[13] Calling method for module MuonIdProducer/'earlyMuons'
Exception Message:
Principal::getByToken: Found zero products matching all criteria
Looking for type: MuonDigiCollection<CSCDetId,CSCStripDigi>
Looking for module label: muonCSCDigis
Looking for productInstanceName: MuonCSCStripDigi
Additional Info:
[a] If you wish to continue processing events after a ProductNotFound exception,
add "SkipEvent = cms.untracked.vstring('ProductNotFound')" to the "options" PSet in the configuration.
----- End Fatal Exception -------------------------------------------------
This clearly needs to be fixed, my question is: if this is not affecting any other standard workflow as it seems, and it is not preventing the basic validation of pre4, can we consider to postpone its fix after pre4 is built? Or do you see further possible issues?
Switching this module off in the configuration allows also the step4 of 1102 to run without problems.
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.
@fabiocos , @slava77 can surely reply more accurately than I can.
In principle this PR implies that digis are available (hence implies that unpacking was done starting from RAW). For any workflow for which this is the case there should be no problem.
The question is, are there RelVal workflows where this is not the case?
I'm happy to work on a patch asap, but I would need inputs to understand better how I should be testing it, as my check with runTheMatrix.py -l limited -i all
clearly failed to spot this issue, as well as the one with TauAnalysis/MCEmbeddingTools/
that was instead spot during integration ...
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.
@battibass indeed this is a bit special case, and only wf 1102.0 implementing it shows this issue. I see that @slava77 has already mentioned it in #26500 .
On 4/19/19 4:18 AM, Carlo Battilana wrote:
I'm happy to work on a patch asap, but I would need inputs to understand
better how I should be testing it, as my check with |runTheMatrix.py -l
limited -i all| clearly failed to spot this issue, as well as the one
with |TauAnalysis/MCEmbeddingTools/| that was instead spot during
integration ...
just rewording the earlier message from @fabiocos
runTheMatrix.py -l 1102.0
and then look for the problem in step4
The error does imply that this PR violated assumptions of RECO sequences
design, which apparently implies that digis are not used directly and
local reco outputs are enough to make everything downstream.
Please remind me the logic why it's the digis and not the calibrated
data (which supposedly can also remove the noisy channels)
dt1DRecHits and csc2DRecHits that are used?
|
@slava77 I understand well that I can run In principle, one could use dt1DRecHits, for the DTs. They come with left/right ambiguities (there are actually 2 recHits per digi), but it can be handled. For CSC I think the situation is more complex. From a discussion I had with @ptcox when starting all this, the interpretation of csc2DRecHits is not trivial as both clustering and combination of wire and strip digi information happens at RecHit building, and it is not straightforward to understand what the counting of csc2DRecHits actually means for cases beyond the ones where you have clear muon track segments. The use of CSC strip digis was in fact chosen as it should be a better proxy for "counting" the activity in a chamber in case a shower occur. |
as discussed in the RECO meeting, we can have a quick solution to simply add the CSC and DT digis to the RECO event content. A better choice perhaps is to allow modifications to module PSets of the RECOfromRECO workflows (which is not possible now). See #26500. |
+1 |
PR description:
This PR adds to the muon object a variable that counts the number of digis per station that are collected in the vicinity of an extrapolated track. Based on this variable, member functions are added to
reco::Muon
to tag showers based on digi information similarly to what is done , for example, in this study.Besides the addition of one more variable to
MuonChamberMatch
(which propagates up to miniAOD), no change toreco::Muon
objects expected.PR validation:
The consistency of the
reco::Muon::nDigisInStation
method with the digi counting made a posteriori in ntuples (used for studies like the ones linked above) has been tested on 1K events of a flat pT muon gun and is available here, in such sample. No discrepancy between the two sources of information was found.Event dumps were used to test that
reco::Muon::hasShowerInStation
andreco::Muon::numberOfShowers
behave as expected.The increase in event size, for slimmedMuons in miniAOD and for the workflow 136.891, was checked to be less than 1%.