-- GiovanniAbbiendi - 2009-09-25

Muon Associators

Introduction

In this page we will describe 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 each reconstructed hit on the muon trajectory to the corresponding simulated hits and viceversa. The Quality of the association is then given by their degree of hit sharing. 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. 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. Nevertheless it can reproduce also the results of the (tracker) track associator when it is run over tracker-tracks.

Other associators use a geometric criterion to match the simulated and reconstructed tracks. The associator by position has been developed specially for muon tracks but is also usable for tracker-tracks. It defines the matching criterion on a reference surface far from the interaction point. The reference can be located either on the muon detectors or in the outermost silicon layers. There are several optional matching criteria, including distance between the reconstructed and the simulated track on the reference surface, eta-phi distance between them, eta-phi distance between the momentum vectors at the reference surface or chi2 matching between the track parameters.

These muon associators are currently used for release validation. For muons this task includes basic performance checks of the reconstruction efficiencies which are performed with single muons generated with a fix pT and uniform distribution in eta and phi. 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). However in this case the quality of the association by hits is a measure of the goodness of the track reconstruction, as generally the more hits are correctly found and fitted in the final track, the better the reconstrution quality. Instead the association task is necessary for studying complex events, where the main issue is muon identification and the fake rates. The release validation tests include checking the performance on such complex events like top or Z decaying to muons, with eventual event pileup.

Associating reconstructed hits

The basic task of association by hits has to handle hits located on all possible tracking subdetectors: in the Inner Tracker (Silicon Strip and Pixel detector) or in 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 object is not allowed to contain any MC Truth information. Therefore this information has to be saved in a different object specifically designed in Monte Carlo for this purpose, 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 hit association is contained 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 on the RECO data format. Therefore association of the Tracker hits is not possible from events in the RECO format. However the necessary DigiSimLinks may be rebuilt on the fly in MC samples in the two-file format RAW+RECO, following the procedure described here.

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 two 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 in it, the EncodedEventId 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 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 in it, the EncodedEventId that the particle belongs to.

The DT DigiSimLinks are produced by the package SimMuon/DTDigitizer and have a special data format corresponding to the specific features of DT drift cells. In particular a DT cell may contain up to three RecHits per event, due to the relatively long maximum drift time (~400 ns) and a typical deadtime of ~100 ns after a RecHit signal. The collection of DT DigiSimLinks is mapped by DT layers, and for each wire it contains the Id of every SimTrack giving a DT Digi and the Id of the proper encoded event. After the arrival on a DT wire of the signal of a particle crossing the cell, the readout has a deadtime of 150 ns. In case of emission of delta rays, following the passage of a muon, it may happen that the delta electrons give signal at the wire before the muon signal. In this case the muon PSimHit is masked. When this happens the DigiSimLink registers the SimTrack Id of the first arriving signal. However, in case two PSimHits are within a time window of the order of the time resolution, they are both accounted, 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 DT DigiSimLinks contains 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). DT and CSC methods have also a specialized interface. The returned vector is not ordered. The user, depending on the analysis scope needs to decide how to choose the best association.

MuonTruth::associateHitId(const TrackingRecHit &); MuonTruth::associateCSCHitId(const CSCRecHit2D *);

DTHitAssociator::associateHitId(const TrackingRecHit & hit); DTHitAssociator::associateDTHitId(const DTRecHit1D * dtrechit);

RPCHitAssociator::associateRecHit(const TrackingRecHit & hit);

The Muon DigiSimLinks corresponding to CSC, DT and RPC are saved in the RECO data format. Therefore the association of RecHits on the muon detectors to the SimTrack Id can be done from RECO files. (CHECK !!!) Other functionalities, which require to return the associated PSimHits and not just their SimTrack Ids, are instead working only if the event format includes the PSimHit collections. Practically this is true in the two-file RAW+RECO format.

The muon hit associators have configurable parameters which have to be parsed. Here a brief description is given. A full working example is pointed out in the section on track association.

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

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

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

• DTdigisimlinkTag input tag of DT DigiSimLinks, usually InputTag("simMuonDTDigis")
• associatorByWire true if associating a RecHit 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 a specific reason. It is less precise than using the DigiSimLinks, usually it is false.
• links_exist true if the events contain the DT DigiSimLinks, usually true.
• crossingframe true if reading PSimHits from the CrossingFrame, necessary for some (non-default) functionalities on events with pile-up, usually false
• DTsimhitsTag input tag of DT PSimHit collection, usually InputTag("g4SimHits","MuonDTHits")
• DTsimhitsXFTag input tag of DT PSimHit collection from the CrossingFrame, usually InputTag("mix","g4SimHitsMuonDTHits")
• dumpDT true for dumping DT hits (sim-digi-links-reco) useful for debug, usually false.
• DTdigiTag input tag of DT Digi collection, for debugging purpose, usually InputTag("simMuonDTDigis")
• DTrechitTag input tag of DT RecHit collection, for debugging purpose, usually InputTag("dt1DRecHits")

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

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

Muon Association

To associate in the optimal way the reconstructed and simulated tracks a special object has been developed called the TrackingParticle. 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 newly developed for muon tracks. Here we mainly describe the two most used associators for muon: the MuonAssociatorByHits and the TrackAssociatorByPosition. The other associators, TrackAssociatorByHits and TrackAssociatorByChi2, are described in the page on Track Associators, where we also point the reader for other common details.

All the associators implement two methods:

• associateRecoToSim: associates reconstructed tracks to TrackingParticles.
• associateSimToReco: associates TrackingParticles to reconstructed tracks.

They return an OneToManyWithQualityGeneric AssociationMap, defined in: DataFormats/RecoCandidate/interface/TrackAssociation.h. This association map, for every Track (TrackingParticle), stores the vector of associated TrackingParticles (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 point to working examples in the following.

MuonAssociatorByHits

The MuonAssociatorByHits associates reco::Tracks and TrackingParticles on the basis of the number of hits they share. WARN: FORSE VUOI METTERE LINKS GENERICI, NON CON LA VERSIONE !!! A TrackingRecHit is shared with a TrackingParticle if the proper hit associator, depending on the subdetector where the hit is, 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. Here we give some explanation of the configurable parameters. The parameters are parsed 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.

• 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 if true print out the reco::Track, TrackingParticle and SimTrack collections, for debugging purpose.
• AbsoluteNumberOfHits_track if true use the absolute number of shared hits on the inner track stub to define the association, if false use 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 if true use the absolute number of shared hits on the muon detectors to define the association, if false use the fraction of shared hits. In each case the Quality of the association of the muon stub is defined accordingly.
• MinHitCut_muon minimum number of shared hits on the muon stub when AbsoluteNumberOfHits_muon = true
• UseTracker if true analyze the track stub on the Inner Tracker, if false do not.
• UseMuon if true analyze the track stub on the Muon detectors, if false do 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 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 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 describe in the previous section. The tracker hit associator is described in the related page for Track Association.

An example configuration can 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)

# 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 the case) to TrackingParticles. The default cut on the fraction of shared hits is 50% both is SimToReco and in RecoToSim association. Wishing to catch all the truth-matched tracks one could lower these cuts as far as requiring just one shared hit. To have the quality expressed as a fraction this can be obtained by setting the cuts at a very low value, which would be passed always with as low as one shared hit, like 1%. Then one will often have more than one association, ordered by quality (the first is the best). The previous example could be change 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)

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. Then 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. With the default cuts there will be only one matching. The following fragment will do this, the definition cuts have been shown even if some of them are defaults:

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 a global muon 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)

A full 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 RelVal primary and secondary input files and to set the GlobalTag according to them. This example is quite verbose since it aims to show what is actually done by the producer. It can be muted by changing the MessageLogger settings. The analyzer is simply reading the association maps and printing out the results. The example analyzes the stand-alone muons but, having FEVT input format, it can do all the possible associations.

Another full example is runnable from input RAW+RECO MC files, SimMuon/MCTruth/test/testMuonAssociatorEDProducer_ReDigi_cfg.py. The example analyzes global muons. To do this one needs to reinstate the tracker DigiSimLinks, and to rebuild the TrackingParticles from PSimHit collections. This is fully supported with the proper setting of the random number engine, where the initial seeds are read in from the events. All this is described in the [[SWGuideSimulation#Special Procedures][Full Simulation] twiki page.

The MuonAssociatorByHits is used for the release validation by using centralized sequences. To see a complete example (though containing a lot of other stuff) you can read about the RecoMuon Validation suite. The RecoMuon validation use as analyzer the MultiTrackValidator, with a dedicated configuration for muon tracks. MultiTrackValidator

TrackAssociatorByPosition

The TrackAssociatorByPosition associates reco::Tracks and TrackingParticles on the basis of their distance at some reference surface far from the interaction point. Given a TrackingParticle the associator determines the TrackStateOnSurface 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 applied by a configurable parameter. The reco::Track to be probed is then propagated with the 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 set the reference surface at the outermost muon layer, if false set it to the outermost tracker layer
• positionMinimumDistance minimum distance from the origin of the outermost PSimHit used to define the reference surface, default is 0.
• QCut maximum distance to associate the reco::Track and the TrackingParticle in the chosen metric, default is 10. (sensible value depends on the chosen metric)
• MinIfNoMatch if true save 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' use a chi2 estimation on the 5x5 local parameters and errors in the reference surface
  • 'dist' use the spatial distance in cm between states in the reference surface
  • 'momdr' use the delta-R (eta-phi) between the momentum vectors at the reference surface
  • 'posdr' use the delta-R (eta-phi) between the position vectors at the reference surface

A fragment of configuration which may 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 delta-R 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 associative maps can be read in and analyzed similarly to what is described for tracker track association. The TrackAssociatorByPosition and the MuonAssociatorByHits are used for the release validation by using centralized sequences. To see a complete example (though containing a lot of other stuff) you can read about the RecoMuon Validation suite.

Review status

Reviewer/Editor and Date (copy from screen)	Comments
GiovanniAbbiendi - 25 Sep 2009	author

%RESPONSIBLE% GiovanniAbbiendi
%REVIEW% GiovanniAbbiendi - 25 Sep 2009