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

Check TrackingParticle ProductID in cluster->TrackingParticle association #13242

Merged
merged 8 commits into from Feb 16, 2016

Conversation

makortel
Copy link
Contributor

The current use of ClusterTPAssociationList in QuickTrackAssociatorByHits is a bit dangerous. Although edm::Refs to TrackingParticles are used in ClusterTPAssociationList, there are no checks done at any point if the Refs point to the same TrackingParticleCollection as those being associated in QuickTrackAssociatorByHits. Possible bugs would have the following symptoms

  • SimToReco association returns nothing for a given TrackingParticle
  • RecoToSim association returns associations of Track to the TrackingParticles used in ClusterTPAssociationList, that are not necessarily the same as were give as arguments

In order to catch such bugs, this PR adds a check for the edm::ProductID of the TrackingParticleCollection to ClusterTPAssociation(List) and QuickTrackAssociatorByHits by encapsulating the "raw" typedef vector<pair<...>> ClusterTPAssociationList as ClusterTPAssociation class that contains also the ProductID of the TrackingParticleCollection. On the same go I did some technical cleanup in ClusterTPAssociationProducer, including turning it to global module and using fillDescriptions().

In addition, QuickTrackAssociatorByHitsImpl::associate...(..., TrackingParticleRefVector) overloads are fixed for the case where the argument TrackingParticlRefVector is a subset of the TrackingParticles used in ClusterTPAssociation. Without the fix, the argument is ignored and the associations are done using the TrackingParticles in ClusterTPAssociation.

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 change TkConvValidator to read TrackingParticleRefVector.

Tested in 8_0_0_pre6, expecting changes only in EgammaV/ConversionValidator DQM folder.

@rovere @VinInn

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.
@cmsbuild
Copy link
Contributor

A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_8_0_X.

It involves the following packages:

FastSimulation/Validation
SimTracker/TrackAssociatorProducers
SimTracker/TrackerHitAssociation
Validation/RecoEgamma
Validation/RecoTrack

@civanch, @lveldere, @ssekmen, @mdhildreth, @cmsbuild, @deguio, @vanbesien, @davidlange6 can you please review it and eventually sign? Thanks.
@istaslis, @GiacomoSguazzoni, @rovere, @richard-cms, @Martin-Grunewald, @matt-komm, @wmtford, @cerati, @VinInn, @threus, @dgulhan this is something you requested to watch as well.
@slava77, @Degano, @smuzaffar you are the release manager for this.

cms-bot commands are list here #13028

@VinInn
Copy link
Contributor

VinInn commented Feb 10, 2016

cmsbuild, please test

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/11132/console

@@ -0,0 +1,68 @@
#ifndef SimTracker_TrackerHitAssociation_ClusterTPAssociation_h
#define SimTracker_TrackerHitAssociation_ClusterTPAssociation_h
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'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> (
Copy link
Contributor Author

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

@slava77
Copy link
Contributor

slava77 commented Feb 10, 2016

@makortel
Is the execution time relatively unchanged?

@makortel
Copy link
Contributor Author

@slava77 I didn't check, but I'd expect it to be. The ClusterTPAssociation itself is inlined except the actual ProductID checking which may throw. In the filling side, i.e. ClusterTPAssociationProducer, the check is done for each cluster-TP pair so there is some penalty. In the reading side, i.e. QuickTrackAssociatorByHits, the check is done only once per associateRecoToSim() and associateSimToReco() calls that do the associations for the entire track and TP collections.

In TkConvValidator side things should be only faster because of reduced copying, but I have no idea (without profiling) if it really shows up in the numbers or not.

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@lveldere
Copy link
Contributor

+1

@cmsbuild
Copy link
Contributor

The tests are being triggered in jenkins.
https://cmssdt.cern.ch/jenkins/job/ib-any-integration/11210/console

@cmsbuild
Copy link
Contributor

@cmsbuild
Copy link
Contributor

@lveldere
Copy link
Contributor

+1

@deguio
Copy link
Contributor

deguio commented Feb 16, 2016

+1

@civanch
Copy link
Contributor

civanch commented Feb 16, 2016

+1

@cmsbuild
Copy link
Contributor

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

@davidlange6
Copy link
Contributor

@deguio - I take your +1 to mean that the e/gamma validation plot changes are ok..

@davidlange6
Copy link
Contributor

+1

cmsbuild added a commit that referenced this pull request Feb 16, 2016
Check TrackingParticle ProductID in cluster->TrackingParticle association
@cmsbuild cmsbuild merged commit d8c2841 into cms-sw:CMSSW_8_0_X Feb 16, 2016
@makortel makortel deleted the clusterTPAssociation branch October 20, 2016 11:52
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

8 participants