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
Check TrackingParticle ProductID in cluster->TrackingParticle association #13242
Conversation
This way we can get rid of a nasty bug: - QuickTrackAssociatorByHits, by default, uses cluster->TrackingParticle mapping, that uses edm::Refs to the original TrackingParticle collection ("mix:MergedTrackTruth") - tpSelecForEfficiency and tpSelecForFakeRate create copies of the TrackingParticles Therefore - for efficiency, because of the copying, the edm::Refs to tpSelecForEfficiency collection differ from refs to "mix:MergedTrackTruth", and therefore no TrackingParticle of tpSelecForEfficiency get matched to any tracks - for fake rate, the tracks are matched to the TrackingParticles of the cluster->TrackingParticle mapping, i.e. "mix:MergedTrackTruth" resulting in empty efficiency plots, and fake rates computed using "mix:MergedTrackTruth" instead of tpSelecForFakeRate.
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_8_0_X. It involves the following packages: FastSimulation/Validation @civanch, @lveldere, @ssekmen, @mdhildreth, @cmsbuild, @deguio, @vanbesien, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are list here #13028 |
cmsbuild, please test |
The tests are being triggered in jenkins. |
@@ -0,0 +1,68 @@ | |||
#ifndef SimTracker_TrackerHitAssociation_ClusterTPAssociation_h | |||
#define SimTracker_TrackerHitAssociation_ClusterTPAssociation_h |
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'm not sure if this is the best package for this event product, but the dictionary for the preceding ClusterTPAssociationList
was defined here.
@@ -142,9 +142,9 @@ TkConvValidator::TkConvValidator( const edm::ParameterSet& pset ) | |||
g4_simTk_Token_ = consumes<edm::SimTrackContainer>(pset.getParameter<edm::InputTag>("simTracks")); | |||
g4_simVtx_Token_ = consumes<edm::SimVertexContainer>(pset.getParameter<edm::InputTag>("simTracks")); | |||
|
|||
tpSelForEff_Token_ = consumes<TrackingParticleCollection> ( | |||
tpSelForEff_Token_ = consumes<TrackingParticleRefVector> ( |
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.
It would be good if somebody from EGM could review this TkConvValidator
part (but I don't know who to ask).
@makortel |
@slava77 I didn't check, but I'd expect it to be. The In |
+1 |
The tests are being triggered in jenkins. |
+1 |
+1 |
+1 |
This pull request is fully signed and it will be integrated in one of the next CMSSW_8_0_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @slava77, @davidlange6, @Degano, @smuzaffar |
@deguio - I take your +1 to mean that the e/gamma validation plot changes are ok.. |
+1 |
Check TrackingParticle ProductID in cluster->TrackingParticle association
The current use of
ClusterTPAssociationList
inQuickTrackAssociatorByHits
is a bit dangerous. Althoughedm::Ref
s toTrackingParticle
s are used inClusterTPAssociationList
, there are no checks done at any point if theRef
s point to the sameTrackingParticleCollection
as those being associated inQuickTrackAssociatorByHits
. Possible bugs would have the following symptomsSimToReco
association returns nothing for a givenTrackingParticle
RecoToSim
association returns associations ofTrack
to theTrackingParticle
s used inClusterTPAssociationList
, that are not necessarily the same as were give as argumentsIn order to catch such bugs, this PR adds a check for the
edm::ProductID
of theTrackingParticleCollection
toClusterTPAssociation(List)
andQuickTrackAssociatorByHits
by encapsulating the "raw"typedef vector<pair<...>> ClusterTPAssociationList
asClusterTPAssociation
class that contains also theProductID
of theTrackingParticleCollection
. On the same go I did some technical cleanup inClusterTPAssociationProducer
, including turning it toglobal
module and usingfillDescriptions()
.In addition,
QuickTrackAssociatorByHitsImpl::associate...(..., TrackingParticleRefVector)
overloads are fixed for the case where the argumentTrackingParticlRefVector
is a subset of theTrackingParticle
s used inClusterTPAssociation
. Without the fix, the argument is ignored and the associations are done using theTrackingParticle
s inClusterTPAssociation
.Running the short matrix revealed one such bug, in
TkConvValidator
. The existing plots from DQM GUI (https://goo.gl/zor134) look indeed to be poisoned by the bug (obviously one can judge only based on the empty efficiency plots). Minimal fix was to changeTkConvValidator
to readTrackingParticleRefVector
.Tested in 8_0_0_pre6, expecting changes only in
EgammaV/ConversionValidator
DQM folder.@rovere @VinInn