Difference: GiovanniAbbiendiMCTruth ( vs. 1)

Revision 12009-10-02 - GiovanniAbbiendi

Line: 1 to 1
Added:
>
>
META TOPICPARENT name="GiovanniAbbiendi"

MC Truth muon associators

%COMPLETE3%

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, eta-phi distance between the position or momentum vectors of the track states on the reference surface, or chi2 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 pT and uniform eta and phi 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 Full Simulation page.

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, 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 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 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 layers. For each DT wire they contain the Id of every SimTrack giving a DTDigi and the encoded Id of the event they belong 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 signal. In this case the muon signal is masked if it comes within the deadtime window of 150 ns. When this happens the DigiSimLink registers the SimTrack Id corresponding to the first arriving signal. However, in case two PSimHits fall 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 contain 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 &);

MuonTruth::associateCSCHitId(const CSCRecHit2D *);

DTHitAssociator::associateHitId(const TrackingRecHit & hit);

DTHitAssociator::associateDTHitId(const DTRecHit1D * dtrechit);

RPCHitAssociator::associateRecHit(const TrackingRecHit & hit);

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 HAS TO BE CHECKED) Other methods which 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-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 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. 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 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

<!-- Add your review status in this table structure with 2 columns delineated by three vertical bars. Add comments for editing, reviewing, etc -->

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

<!-- Here the "responsible" is the contact person for maintenance of the page - often initially the page author -->
<!-- The "review" person is the most recent person to carry out a full review of the page  - on this field please include the date in the format shown -->
%RESPONSIBLE% GiovanniAbbiendi
%REVIEW% GiovanniAbbiendi - 2 Oct 2009
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback