-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Fix sorting of values in QuickTrackAssociatorHitsByImpl #8540
Conversation
…HitsImpl Not doing so results differences when reading the associations from the event compared to doing the association on the fly.
A new Pull Request was created by @makortel (Matti Kortelainen) for CMSSW_7_5_X. Fix sorting of values in QuickTrackAssociatorHitsByImpl It involves the following packages: SimTracker/TrackAssociatorProducers @cmsbuild, @civanch, @nclopezo, @mdhildreth can you please review it and eventually sign? Thanks. |
+1 |
This pull request is fully signed and it will be integrated in one of the next CMSSW_7_5_X IBs unless changes (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @nclopezo, @ktf, @smuzaffar |
+1 |
Fix sorting of values in QuickTrackAssociatorHitsByImpl
In case SimToRecoCollection (RecoToSimCollection) has more than 1 track associated to a TrackingParticle (vice versa), in the collection returned by QuickTrackAssociatorHitsByImpl these tracks (TPs) are not sorted by the matching quality. However, edm::Event::put() calls the AssociatorMap::post_insert() (which does the sorting) when a product is inserted to Event. This behaviour can create a subtle difference in cases where the SimToRecoCollection/RecoToSimCollection is read from an Event and where they are produced on the fly.
This PR makes the return values of QuickTrackAssociatorHitsByImpl to be always sorted (the association wrt. TrajectorySeed was already sorted, and that is also the behaviour in other TrackAssociators). I deliberately fixed only the new-style associator, as I intend to clean up the old-style associators in a separate PR.
Tested in 750pre1 with 9k RelValTTbar events. Tiny changes are expected in DQM plots utilizing the track-TP associations such that something from the value of the association is plotted. Couple of examples from MultiTrackValidator for all tracks (black old, red new):
Especially the efficiencies and fake rates reported by MTV should not be affected, but duplicate rate can be, as demonstrated by this plot from HLT tracks
@rovere @VinInn