MC Truth muon associators

Complete:

Introduction

This page describes the available Monte Carlo tools to associate the reconstructed muon tracks (standalone, global, tracker muons, L2/L3 HLT muons...) to the actual simulated tracks which they come from. This MC Truth information is valuable to study the performance of tracking algorithms (efficiency, fake rates, resolution...) in the different physics analyses. Currently it is also used for muon validation across the CMSSW releases.

The muon associators share many concepts and some basic code with the tracker track associators.

The muon associator by hits is naturally unambiguous. It associates the reconstructed hits on the muon trajectory to the corresponding simulated hits and viceversa. The Quality of the association is then given by the degree of hit sharing between the reconstructed and the simulated track. When a muon candidate has a track stub on the muon detectors (like for global muons or tracker muons) it can be assigned two different qualities, corresponding to the association by hits of the tracker and the muon stub. This is particularly relevant in the case of muons from decays in flight or fake muons from hadron punchthrough, where the two qualities may be quite different. Due to this peculiar feature the muon associator by hits has been developed in a completely independent way from the corresponding (tracker) track associator by hits.

Other associators use a geometric criterion to match the simulated and reconstructed tracks. The associator by position defines the matching on a reference surface far from the interaction point, which can either coincide with a layer on the muon detectors or with one of the outermost silicon tracker layers. It can use several matching criteria, including distance between the reconstructed and the simulated track on the reference surface, distance between the position or momentum vectors of the track states on the reference surface, or matching between the two states at the reference surface.

These muon associators are currently used for release validation. Muon validation includes basic performance checks of the reconstruction efficiencies which are evaluated with single muons generated with a fix and uniform and distributions. Obviously the task of associating is in this case quite trivial as the reconstructed muons cannot come from anything else than the generated single muons (actually, for practical convenience, the muons are generated in back-to-back pairs with opposite charges, but this is still a rather unambiguous topology). Nevertheless the Quality of the Sim-to-Reco association by hits is a measure of the quality of the pattern recognition and hence, to some extent, of the overall reconstruction quality. Instead, the Quality of the Reco-To-Sim association by hits is a test of the purity of the reconstructed tracks, sensitive to the presence of extraneous (spurious) hits. Muon validation includes also identification and reconstruction in complex events like top or Z decaying to muons, with eventual pileup: in these cases the association task and the estimate of fake rates is non-trivial. Having two complementary associators, one properly unambiguous and the other geometry-based, has proved to be quite useful to quickly spot bugs in the geometry or in the reconstruction.

Associating reconstructed hits

Muon association by hits has to deal with hits on every tracking detector: on the Inner Tracker (Silicon Strip and Pixel detector) or on the Muon detectors (DT, CSC, RPC). The reconstructed hits (RecHits) on each subdetector have to be associated to the simulated hits (PSimHits) which they come from. Since the RecHit collections in Monte Carlo events have to be equivalent to those in real data, the RecHit objects are not allowed to contain any MC Truth information. Therefore this information has to be saved in a different object specifically designed for Monte Carlo, the DigiSimLink. The DigiSimLinks are produced during the digitization step, immediately after the simulation step, and may have a specific data format for each subdetector.

For the Inner Tracker the DigiSimLinks are produced by the packages SimTracker/SiStripDigitizer and SimTracker/SiPixelDigitizer. The code for tracker hit association is in the package SimTracker/TrackerHitAssociation. A description of the relevant methods and of the DigiSimLinks data formats is contained in the reference page for tracker track associators. The Tracker DigiSimLink collections are part of the FEVT data format, but are dropped in the RECO data format. Therefore association of the Tracker hits is not possible from events in the RECO format. However the necessary tracker DigiSimLinks may be rebuilt on the fly in MC samples in two-files format RAW+RECO, following the procedure described in the Full Simulation page. A complete example is described in the next section.

The CSC DigiSimLinks are produced by the package SimMuon/CSCDigitizer and consist of two collections, one for CSC strip digis and one for CSC wire digis. Both of them use the same data format StripDigiSimLink, which is also used by the Inner Tracker DigiSimLinks. For each strip or wire readout channel it contains the Id of every SimTrack that deposited some amount of charge, the encoded Id of the event that the particle belongs to, and the fraction of the charge deposited by the SimTrack with respect to the total charge deposited on that particular detector channel. The collections use as container edm::DetSetVector.

The RPC DigiSimLinks are produced by the package SimMuon/RPCDigitizer. They use a dedicated data format, RPCDigiSimLink, which, among other informations, contains the detector unit Id, the Id of every SimTrack that deposited some amount of charge on it, and the encoded Id of the event that the particle belongs to. The collection uses the container type edm::DetSetVector.

The DT DigiSimLinks are produced by the package SimMuon/DTDigitizer and have a special data format, DTDigiSimLink, corresponding to the specific features of DT drift tubes. In particular a DT cell may contain up to three RecHits per event, due to the relatively long maximum drift time (~400 ns) and the typical deadtime of ~150 ns after registering a hit signal. The collection of DT DigiSimLinks is mapped by DT layer in a container type MuonDigiCollection. For each DT digitized signal the DTDigiSimLink contains the Id of the corresponding SimTrack and the encoded Id of the event it belongs to. In case of emission of delta rays, accompanying the passage of a muon through a DT cell, it may happen that the delta electrons give signal at the wire before the primary muon. In this case the muon signal is masked if it falls within a deadtime window of 150 ns. When this happens the DTDigiSimLink registers the SimTrack Id corresponding to the first arriving signal. However, in case two PSimHits have a time difference of the order of the time resolution, they are both accounted for, as presumably the real signal would integrate both (actually in the DTDigitizer this is defined by a configurable parameter LinksTimeWindow with default value 10 ns). To specify completely the link between PSimHits and Digis the DTDigiSimLinks contain the wire number on the layer, the digi number (which may be 0, 1, 2) and the drift time, expressed in number of TDC counts.

The hit association code is contained in the SimMuon/MCTruth package. There is one specialized class for each of the three muon subdetectors: MuonTruth (for CSC), DTHitAssociator (for DT), RPCHitAssociator (for RPC). The following methods return, for an input TrackingRecHit, a vector of SimTrack Id paired with the EncodedEventId of the associated PSimHits (the encoded event Id is necessary in case of events with pile-up). The returned vector is not ordered. The user, depending on the analysis, needs to decide how to choose the best association.

MuonTruth::associateHitId(const TrackingRecHit &);

DTHitAssociator::associateHitId(const TrackingRecHit & hit);

RPCHitAssociator::associateRecHit(const TrackingRecHit & hit);

DT and CSC associators have also specific interfaces:

MuonTruth::associateCSCHitId(const CMS.CSCRecHit2D *);

DTHitAssociator::associateDTHitId(const DTRecHit1D * dtrechit);

Different from the case of the Inner Tracker, the Muon DigiSimLinks corresponding to CSC, DT and RPC are saved in the RECO data format. Therefore the association of RecHits in the muon detectors to the SimTrack Id can be done from RECO files. This can be done within a analyzer module, which does the Association By Hits internally, with a special configuration of the TrackingParticle producer (working when there are no PSimHits in the Event) and a special configuration of the MuonAssociatorByHits. A simple example (may be obsolete) is shown in SimMuon/MCTruth/test/testAssociatorRecoMuon_cfg.py, the analyzer code is at: SimMuon/MCTruth/test/testAssociatorRecoMuon.cc. A more complete example, describing some useful analysis code which can be built on muon association by hits, is given in another twiki page describing the package MuonAnalysis/MuonAssociators.

Other methods which return the associated PSimHits and not just their SimTrack Ids, are working only if the event format includes the PSimHit collections. Practically this requires at least the two-files RAW+RECO format.

The muon hit associators have configurable parameters which need to be parsed. Here a brief description is given. Full working examples are given for muon track association.

The CSC hit associator (class MuonTruth) is configured by:

• CSClinksTag InputTag of CSC strip DigiSimLinks, usually ("simMuonCSCDigis","MuonCSCStripDigiSimLinks")
• CSCwireLinksTag InputTag of CSC wire DigiSimLinks, usually ("simMuonCSCDigis","MuonCSCWireDigiSimLinks")
• crossingframe (default false) if true the PSimHits are taken from the CrossingFrame, this is necessary for some functionalities on events with pile-up
• CSCsimHitsTag InputTag of CSC PSimHit collection, usually ("g4SimHits","MuonCSCHits")
• CSCsimHitsXFTag Input tag of CSC PSimHit collection from the CrossingFrame, usually ("mix","g4SimHitsMuonCSCHits")

The DT hit associator (class DTHitAssociator) is configured by:

• DTdigisimlinkTag InputTag of DT DigiSimLinks, usually ("simMuonDTDigis")
• associatorByWire (default false) if true any RecHit is associated to all the valid PSimHits on its DT cell: this may be used if for some reason the events do not contain the DT DigiSimLinks, or for other specific reasons. It is less precise than using the DigiSimLinks.
• links_exist true (default) means that the events contain the DT DigiSimLinks.
• crossingframe (default false) if true the PSimHits are taken from the CrossingFrame, this is necessary for some functionalities on events with pile-up
• DTsimhitsTag InputTag of DT PSimHit collection, usually ("g4SimHits","MuonDTHits")
• DTsimhitsXFTag InputTag of DT PSimHit collection from the CrossingFrame, usually ("mix","g4SimHitsMuonDTHits")
• dumpDT (default false) if true dumps the DT hits (sim-digi-links-reco) by wire, useful for debugging.
• DTdigiTag InputTag of DT Digi collection, for debugging purpose, usually ("simMuonDTDigis")
• DTrechitTag Input tag of DT RecHit collection, for debugging purpose, usually ("dt1DRecHits")

The RPC hit associator (class RPCHitAssociator) is configured by:

• RPCdigisimlinkTag InputTag of RPC DigiSimLinks, usually ("simMuonRPCDigis","RPCDigiSimLink")
• crossingframe (default false) if true the PSimHits are taken from the CrossingFrame
• RPCsimhitsTag InputTag of RPC PSimHit collection, usually ("g4SimHits","MuonRPCHits")
• RPCsimhitsXFTag InputTag of RPC PSimHit collection from the CrossingFrame, usually ("mix","g4SimHitsMuonRPCHits")

Associating reconstructed Tracks

To associate in the optimal way the reconstructed and simulated tracks a special object has been developed, the TrackingParticle. Basically the TrackingParticle gives access to all the PSimHits composing a simulated track and to all the related MC Truth information. The TrackingParticle collection is normally produced during the digitization step, after the simulation step. It is included in the FEVT format, typical of CMS.RelVal generations. Instead it is not saved in RAW data format but it can be easily rebuilt from it. From RECO it is not possible to rebuild it, as RECO does not contain the PSimHit collections. More details and a description of the TrackingParticle producer are given in another twiki page.

Since a muon track is first of all just a track, all the Track Associators can be used, including those developed for tracker tracks.

In addition the MuonAssociatorByHits, as said in the introduction, has been specially developed for muon tracks.

Here we mainly describe the two most used associators for muon tracks: the MuonAssociatorByHits and the TrackAssociatorByPosition. The other associators, TrackAssociatorByHits and TrackAssociatorByChi2, are described in the page on Track Associators, where we also address the reader for other common details.

All the associators implement two methods:

• associateRecoToSim: associates reco::Tracks to TrackingParticles.
• associateSimToReco: associates TrackingParticles to reco::Tracks.

They return a OneToManyWithQualityGeneric AssociationMap, defined in: DataFormats/RecoCandidate/interface/TrackAssociation.h.

This association map stores for every reco::Track (TrackingParticle) the vector of associated TrackingParticles (reco::Tracks) and the quality of the association. The vector is ordered from the element with the best quality to the element with the worst. We leave other details to the page on Track Associators, and will show examples in the following.

MuonAssociatorByHits

The MuonAssociatorByHits associates reco::Tracks and TrackingParticles on the basis of the number of hits they share. Given a reco::Track, a TrackingRecHit is shared with a TrackingParticle if the proper hit associator (depending on the subdetector) returns at least one of the SimTrack Ids belonging to the TrackingParticle. The best use of the associator is through an EDProducer, MuonAssociatorEDProducer, which puts in the edm::Event the association maps resulting from the association. The default configuration of the producer is given in: SimMuon/MCTruth/python/MuonAssociatorByHits_cfi.py. The configurable parameters are passed to the producer as a ParameterSet, which is then passed in cascade to the muon track associator and to the individual (tracker and muon) hit associators. They are:

• tracksTag InputTag of the reco::Track collection to analyze
• tpTag InputTag of the TrackingParticle collection, default is ("mergedtruth","MergedTrackTruth")
• ignoreMissingTrackCollection (default = false) if true the producer will not complain of events where the chosen track collection is missing, otherwise an exception is issued
• dumpInputCollections (default = false) if true prints out the reco::Track, TrackingParticle and SimTrack collections, for debugging purpose
• AbsoluteNumberOfHits_track (default = false) if true uses the absolute number of shared hits on the inner track stub to define the association, if false uses the fraction of shared hits. In each case the Quality of the association of the inner track stub is defined accordingly
• MinHitCut_track minimum number of shared hits on the inner track stub when AbsoluteNumberOfHits_track = true
• AbsoluteNumberOfHits_muon (default = false) if true uses the absolute number of shared hits on the muon detectors to define the association, if false uses the fraction of shared hits. In each case the Quality of the association on the muon stub is defined accordingly
• MinHitCut_muon minimum number of shared hits on the muon stub when AbsoluteNumberOfHits_muon = true
• UseTracker if true analyzes the track stub on the Inner Tracker, if false does not.
• UseMuon if true analyzes the track stub on the Muon detectors, if false does not.

The following parameters define the associations when the quality is given as fraction of shared hits (i.e. when AbsoluteNumberOfHits_track = false for the inner track stub, or AbsoluteNumberOfHits_muon = false for the muon stub)

• PurityCut_track cut on the number of shared hits w.r.t the total number of RecHits in the inner track stub (usually 0.5 - 0.75)
• PurityCut_muon cut on the number of shared hits w.r.t the total number of RecHits in the muon stub (usually 0.5 - 0.75)
• EfficiencyCut_track cut on the number of shared hits w.r.t the total number of PSimHits in the inner track stub (usually 0.5)
• EfficiencyCut_muon cut on the number of shared hits w.r.t the total number of PSimHits in the muon stub (usually 0.5)
• UseGrouped if true (default), the TrackingParticle hits are counted including all the simulated hits in the tracker layers: this option has to be used if the track has been reconstructed using the GroupedTrajectoryBuilder. If it is false only one hit per layer is computed (to be used for TrajectoryBuilder).
• UseSplitting if false the hits in strip matched layers count one for the number of TrackingParticle hits. If true (default) both hits (mono and stereo) contribute: this option has to be set to true when the matched hits are split before the Final Fit.
• UsePixels if true (default) the pixel hits are counted for the number of TrackingParticle hits. If false they are not: set it to true only for pixel-less tracking.
• ThreeHitTracksAreSpecial if true (default) the tracks with a number of hits equal to three are associated only if they have all the hits shared.

The remaining parameters are those needed by the individual hit associators. The three muon subdetectors have their specific hit associators, with parameters described in the previous section. The tracker hit associator is described in the related page for Track Association.

An example configuration could include this fragment:

# MuonAssociatorByHits
process.load("SimMuon.MCTruth.MuonAssociatorByHits_cfi")
process.muonAssociatorByHits.tracksTag = cms.InputTag("standAloneMuons")
process.muonAssociatorByHits.UseTracker = cms.bool(False)
process.muonAssociatorByHits.UseMuon = cms.bool(True)
process.muonAssociatorByHits.PurityCut_muon = cms.double(0.5)
process.muonAssociatorByHits.EfficiencyCut_muon = cms.double(0.5)

# test analysis
process.testanalyzer = cms.EDAnalyzer("testReader",
    tracksTag = cms.InputTag("standAloneMuons"),
    tpTag = cms.InputTag("mergedtruth","MergedTrackTruth"),
    assoMapsTag = cms.InputTag("muonAssociatorByHits")
)

This would associate stand-alone muons (before the vertex constraint in this case) to TrackingParticles. The cut on the fraction of shared hits is set here to 50% both in SimToReco and in RecoToSim association. The returned quality of the associations is given by the fraction of shared hits. The test analyzer showing how the association maps are read is contained in the SimMuon/MCTruth package ( SimMuon/MCTruth/test/testReader.cc ). A complete example configuration file is SimMuon/MCTruth/test/testMuonAssociatorEDProducer_cfg.py. This starts from RelVal files which have to be specified in input.

Wishing to catch all the truth-matched tracks one could lower the cuts as far as requiring just one shared hit. This can be obtained by setting the efficiency and purity cuts at a very low value, which would be passed always, like 1%. Then one will often have more than one association, ordered by quality (the first is the best). The previous example could be changed by adding a few lines as:

process.load("SimMuon.MCTruth.MuonAssociatorByHits_cfi")
process.muonAssociatorByHits.tracksTag = cms.InputTag("standAloneMuons")
process.muonAssociatorByHits.UseTracker = cms.bool(False)
process.muonAssociatorByHits.UseMuon = cms.bool(True)
process.muonAssociatorByHits.PurityCut_muon = cms.double(0.01)
process.muonAssociatorByHits.EfficiencyCut_muon = cms.double(0.01)

Alternatively one could set

process.muonAssociatorByHits.AbsoluteNumberOfHits_muon = cms.bool(True)
process.muonAssociatorByHits.MinHitCut_muon = cms.uint32(1)

In the latter case the association quality would be equal to the absolute number of shared hits.

As we said the MuonAssociatorByHits can also be used to associate tracker tracks. The following fragment could be used and it should produce the same results as using the TrackAssociatorByHits (with a corresponding configuration)

process.load("SimMuon.MCTruth.MuonAssociatorByHits_cfi")
process.muonAssociatorByHits.tracksTag = cms.InputTag("generalTracks")
process.muonAssociatorByHits.UseTracker = cms.bool(True)
process.muonAssociatorByHits.PurityCut_track = cms.double(0.75)
process.muonAssociatorByHits.EfficiencyCut_track = cms.double(0.5)
process.muonAssociatorByHits.UseMuon = cms.bool(False)

The association of global muons is done by associating separately the tracker stub and the muon stub with the configurable definition cuts. In other words the cut has to be satisfied by the separate tracker and muon stub. With the default cuts there will be only one matching. With lower cuts, in case of more than one matching the results are ordered according to a global quality which is evaluated by considering all the hits on the same foot. The following fragment will associate globalMuons:

process.load("SimMuon.MCTruth.MuonAssociatorByHits_cfi")
process.muonAssociatorByHits.tracksTag = cms.InputTag("globalMuons")
process.muonAssociatorByHits.UseTracker = cms.bool(True)
process.muonAssociatorByHits.PurityCut_track = cms.double(0.75)
process.muonAssociatorByHits.EfficiencyCut_track = cms.double(0.5)
process.muonAssociatorByHits.UseMuon = cms.bool(True)
process.muonAssociatorByHits.PurityCut_muon = cms.double(0.5)
process.muonAssociatorByHits.EfficiencyCut_muon = cms.double(0.5)

In case one wants to analyze only the muon stub of global muons one could use this:

process.load("SimMuon.MCTruth.MuonAssociatorByHits_cfi")
process.muonAssociatorByHits.tracksTag = cms.InputTag("globalMuons")
process.muonAssociatorByHits.UseTracker = cms.bool(False)
process.muonAssociatorByHits.UseMuon = cms.bool(True)
process.muonAssociatorByHits.PurityCut_muon = cms.double(0.5)
process.muonAssociatorByHits.EfficiencyCut_muon = cms.double(0.5)

Similarly one could analyze only the tracker stub of global muons with:

process.load("SimMuon.MCTruth.MuonAssociatorByHits_cfi")
process.muonAssociatorByHits.tracksTag = cms.InputTag("globalMuons")
process.muonAssociatorByHits.UseTracker = cms.bool(True)
process.muonAssociatorByHits.PurityCut_track = cms.double(0.75)
process.muonAssociatorByHits.EfficiencyCut_track = cms.double(0.5)
process.muonAssociatorByHits.UseMuon = cms.bool(False)

A complete example which is runnable on FEVT MC files, like the RelVal samples is SimMuon/MCTruth/test/testMuonAssociatorEDProducer_cfg.py. There you have just to include the CMS.RelVal primary and secondary input files and to set the CMS.GlobalTag according to them. This example gives quite a verbose output, since it aims to show what is actually done by the producer. It can be muted by changing the MessageLogger settings. The analyzer simply reads the association maps and prints out the results. By modifying the example one could do all the possible associations on event samples in the FEVT data format.

Another example is runnable from input RAW+RECO MC files, SimMuon/MCTruth/test/testMuonAssociatorEDProducer_ReDigi_cfg.py. This analyzes global muons. To do this from RAW+RECO events one needs to reinstate the tracker DigiSimLinks and to rebuild the TrackingParticle collection. This is fully supported with the proper setting of the random number engine, where the initial seeds are read in from the events. The procedure is documented also in the Full Simulation twiki page.

The MuonAssociatorByHits is employed in the release validation through default standard sequences. To know more on these centralized configurations and try a complete example (though containing a lot of other stuff) you can read about the RecoMuon Validation suite. The RecoMuon validation uses as analyzer the MultiTrackValidator, with a dedicated configuration for muon tracks.

TrackAssociatorByPosition

The TrackAssociatorByPosition associates reco::Tracks and TrackingParticles on the basis of their distance at a reference surface far from the interaction point. The associator by position has been developed specially for muon tracks but is also usable for tracker-tracks. Given a TrackingParticle the associator determines the TrackStateOnSurface (TSOS) corresponding to its outermost hit either on a silicon tracker layer or on the muon detectors. The choice between outermost layer of the silicon tracker or of the muon detectors is defined by a configurable parameter. The reco::Track to be probed is then propagated with the CMS.SteppingHelixPropagator until it intersects the same detector surface and its TrackStateOnSurface is evaluated there. This propagation uses the magnetic field map and the detailed geometry to evaluate also the expected average energy loss and the uncertainties related to multiple scattering. After finding the two TSOS for the reco::Track and the TrackingParticle their distance is evaluated according to the metric chosen in the configuration. The default configuration is given in: SimTracker/TrackAssociation/python/TrackAssociatorByPosition_cfi.py. Practically this is used to configure an ESProducer which defines the proper configuration, then the association map producer, an EDProducer, is run with only a few input parameters. Here we give some explanation of the configurable parameters.

• ComponentName string defining the label of the ESProducer, default is 'TrackAssociatorByPosition'
• propagator string defining the track propagator, default is 'SteppingHelixPropagatorAlong'
• ConsiderAllSimHits if true sets the reference surface at the outermost muon layer, if false set it to the outermost tracker layer
• positionMinimumDistance minimum distance of the outermost PSimHit from the origin, used to define the reference surface, default is 0.
• QCut maximum distance to associate the reco::Track and the TrackingParticle in the chosen metric (a sensible value depends on the chosen metric)
• MinIfNoMatch if true saves the candidate matching with the lowest distance even if this exceeds QCut, default is false.
• method string defining the metric to evaluate distances. There are a few possibilities:
  • 'chi2' uses a estimation on the 5x5 local parameters and errors at the reference surface
  • 'dist' uses the spatial distance in cm between states at the reference surface
  • 'momdr' uses the between the momentum vectors at the reference surface
  • 'posdr' uses the between the position vectors at the reference surface

A configuration fragment which could be used is:

process.load("SimTracker.TrackAssociation.TrackAssociatorByPosition_cff")
process.TrackAssociatorByPosition.ComponentName = cms.string('TrackAssociatorByDeltaR')
process.TrackAssociatorByPosition.method = cms.string('momdr')
process.TrackAssociatorByPosition.QCut = cms.double(0.5)
process.TrackAssociatorByPosition.ConsiderAllSimHits = cms.bool(True)

process.tpToGlbMuAssociation = cms.EDProducer('TrackAssociatorEDProducer',
    associator = cms.string('TrackAssociatorByDeltaR'),
    label_tp = cms.InputTag('mergedtruth', 'MergedTrackTruth'),
    label_tr = cms.InputTag('globalMuons')
)

This will associate global muons to TrackingParticles (and viceversa) when the of their momenta at the reference surface is less than QCut=0.5. The reference is set to the muon layer corresponding to the outermost simulated hit. Then the produced association maps can be read in and analyzed similarly to what is described for tracker track association.

The TrackAssociatorByPosition is employed in the release validation through default standard sequences. To know more on these centralized configurations and try a complete example (though containing a lot of other stuff) you can read about the RecoMuon Validation suite. The RecoMuon validation uses as analyzer the MultiTrackValidator, with a dedicated configuration for muon tracks.

Review status

Reviewer/Editor and Date (copy from screen)	Comments
GiovanniAbbiendi - 2 Oct 2009	author

Responsible: GiovanniAbbiendi
Last reviewed by: GiovanniAbbiendi - 2 Oct 2009