Fix calculation of TrackingParticle::numberOfHits() #17382
Conversation
Because the processType and particleType are taken from the "first" SimHit of a SimTrack, it is important to get the "first" right. Previously it was the one with the smallest index in the SimHit vector, but this fails for Phase2 tracker where also the outer tracker (OT) SimHits are in the same event products as pixel SimHits, and for some reason the OT SimHits are inserted before the pixel SimHits. I believe using the time of flight is more robust way to decide which SimHit is "first".
These are anyway ignored from the number of hit calculation, so let's ignore them from the "first hit" deduction as well.
|
@cmsbuild, please test |
|
The tests are being triggered in jenkins. |
|
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_9_0_X. It involves the following packages: SimGeneral/TrackingAnalysis @cmsbuild, @civanch, @mdhildreth, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
|
@makortel Thanks |
|
@slava77 I must admit that I have not checked the impact on timing. In In |
|
Comparison job queued. |
|
Comparison is ready @slava77 comparisons for the following workflows were not done due to missing matrix map:
|
|
+1 |
cmsbuild
added
fully-signed
simulation-approved
and removed
pending-signatures
simulation-pending
labels
|
This pull request is fully signed and it will be integrated in one of the next CMSSW_9_0_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @smuzaffar |
|
+1 |
The
TrackingParticle::numberOfHits()(and the two other "number of hits") is calculated in a loop over the SimHits of a SimTrack, where only SimHits with the sameparticleTypeas the SimTrack'spdgIdand the sameparticleTypeandprocessTypeas the "first hit" (or that's how the intention looks like). The purpose seems to be to ignore hits from e.g. delta rays or decays where the same SimTrack is reused.I agree with the intention, but the definition of "first hit" is flawed. When iterating over the
multimapfrom SimTrack id to an index in avector<const PSimHit*>inhttps://github.com/cms-sw/cmssw/blob/CMSSW_9_0_0_pre2/SimGeneral/TrackingAnalysis/plugins/TrackingTruthAccumulator.cc#L637-L674
the SimHits of a SimTracks are iterated in the order they get inserted in the
multimapinhttps://github.com/cms-sw/cmssw/blob/CMSSW_9_0_0_pre2/SimGeneral/TrackingAnalysis/plugins/TrackingTruthAccumulator.cc#L563-L566
The order of SimHits originates from
https://github.com/cms-sw/cmssw/blob/CMSSW_9_0_0_pre2/SimGeneral/TrackingAnalysis/plugins/TrackingTruthAccumulator.cc#L515-L530
and
https://github.com/cms-sw/cmssw/blob/CMSSW_9_0_0_pre2/SimGeneral/TrackingAnalysis/plugins/TrackingTruthAccumulator.cc#L306-L314
https://github.com/cms-sw/cmssw/blob/CMSSW_9_0_0_pre2/SimGeneral/MixingModule/python/trackingTruthProducer_cfi.py#L11-L27
i.e. first muon detectors, then pixel, and last (strip) tracker. If the "first hit" (according to the current logic) has
particleTypedifferent from the SimTrack'spdgId, the resultingnumberOfHitsis zero. In phase0/1 this can happen if a non-muon particle decays to a muon resulting hit(s) in muon detectors. In phase2 the problem is exacerbated because also outer tracker SimHits are stored in the "pixel hit" collections, and for some reason for some SimTracks the OT SimHits have smaller index than pixel SimHits (typically leading tonumberOfHits()being 0).The proposed fix is to sort the SimHits by their
timeOfFlight()before being inserted to themultimap, and ignore SimHits havingparticleTypedifferent from TrackingParticlepdgIdfrom the "first hit"particleType+processTypededuction (they are anyway ignored from thenumberOfHitscalculation already now).But even this is not perfect, as there are cases where e.g. all SimHits have
particleTypedifferent from TrackingParticlepdgId. So some further thought is still needed, but I think this PR is nevertheless an improvement. Similar fix is applied toTrackingParticleNumberOfHitsas well.Given that prior #17338 the TrackingParticles with
numberOfHits()==0were ignored inQuickTrackAssociatorByHits, this bug caused some legitimate track-TrackingParticle pairs to not be associated. Already alone this PR would give almost the same changes in track true/fake classification as #17338 (there are cases where all SimHits of a TrackingParticle have a differentparticleTypefrom the TrackingParticlepdgId, so #17338 was anyway needed). On top of #17338, the plots showing the number of hits or layers are expected to show small changes.Tested in CMSSW_9_0_X_2017-01-22-2300 (on top of #17338), expected changes in validation plots are described above. No changes are expected in reco quantities.
@rovere @VinInn @ebrondol @slava77