Track Reconstruction Sequences

Complete:
Detailed Review status

Goals of this page

This tutorial is intended to give an overview of the Track Reconstruction in CMSSW. It is divided into three sections. The first section gives an introduction about set-up of the environment and configuration files. The second one describes briefly the different Track Reconstruction steps and how to configure Parameter Sets to run the Track Reconstruction on different generated MC samples. Finally, the last section gives additional information about more advanced operations involving Tracks.

Contents

• Part One
  • Introduction
  • Set up your Environment
  • Overview of the Configuration Files
• Part Two
  • Generation of the data samples
  • Reconstruction steps Overview
  • Local Reconstruction
  • Track Reconstruction
  • Iterative Tracking
  • How to run the Reconstruction Process
• Part Three
  • Refitting Tracks
  • Electron tracking and GSF
  • Regional and partial tracking (for HLT)
  • Accessing the hit pattern of a track
  • Accessing the track trajectory at each detector layer
  • Accessing the track trajectory at any point in space
• Review status

---

Part One

---

Introduction

Track reconstruction uses primarily signals in the tracking detectors to measure tracks of elementary particles. The reconstruction process is divided into an initial phase where starting points for tracks are found ("Seed Finding") followed by the collection of all measurements corresponding to a track ("Pattern Recognition"). The final step consists of a fit of the collected measurements ("Final Fit") which produces tracks.

Currently, two different ideas have been realized in CMSSW. The first uses both the Pixel and the Strip Detector for Seed Finding (GlobalMixedSeedFinder) and an iterative process going from layer to layer of the tracker detectors taking into account multiple scattering for the Pattern Recognition step using Kalman Filter techniques (CombinatorialTrackFinder or KFTrackCandidateMaker). This is the default Pattern Recognition algorithm in CMSSW: all the studies for TDR were carried out with CTF. The second algorithm uses only the Strip Tracker for Seed Finding (RoadSearchSeedFinder) and opens up Roads around the Seed Trajectories to collect measurements. Following both implementations, a final fit using Kalman Filter techniques (KFFinalFit or TrackProducer) produces the tracks. The modular structure followed during the implementation of the tracking in CMSSW allows the exchange of different components of the two implementations and opens up the possibility to easily integrate new ideas for reconstructing tracks. Since CMSSW_2_1_0, the default CTF reconstruction has been modified employing an Iterative Tracking approach.

The input samples for this tutorial are generated, simulated and digitized using the standard settings of CMSSW. The flow of Local and Track Reconstruction of a digitized MC sample is given in the following figure:

In this tutorial, we'll take you through the steps from the generation of the samples up to the track reconstruction, explaining how to configure a proper Parameter-Set for this task and the meaning of its elements.

Set up your Environment

Set your runtime environment (shown for release %WBRELEASENEW%):
cd CMSSW_%WBRELEASENEW%/src
cmsenv

• Full instructions
• Summary for every login session
• Access modules from the CVS repository.

Overview of the Configuration Files

As explained in details in the specific section of the WorkBook about Configuration Files, the cfg file you pass to the cmsRun command can include other configuration files specific to each process or to each module you need to run. The cff files can contain any fragment of a configuration file whereas the cfi files hold the configuration file for one and only one module. In general, a cfi file is named after the label of the included module.

All the configuration files needed for standard Track Reconstruction are already present in CMSSW releases: our task is to address you to the proper files to include in your private cfg file, to explain the meaning of their elements and to show how to change their settings.

---

Part Two

---

Generation of the data samples

The generation, simulation and digitization chain is described in separate tutorials, for example: Generation, How to produce simu+digi data from generated Monte Carlo, How to use cmsDriver command. Please look at these for details of these processes.

Reconstruction Steps Overview

The reconstruction process starts with the local reconstruction of digis and ends producing Tracks. All the modules needed to complete the process have been gathered in two cff files: CMS.RecoLocalTracker_cff.py and RecoTracker_cff.py.

CMS.RecoLocalTracker_cff.py is responsible for the Local Reconstruction process, while RecoTracker_cff.py is responsible for the Global (or Track) Reconstruction.

CMS.RecoLocalTracker_cff.py and RecoTracker_cff.py are included in a more complete configuration file: Reconstruction_cff.py. This file collects the parameters sets for local and global reconstruction of all detectors and for higher level objects (e.g. Vertices). A detailed description of this file is beyond the purposes of this section of the WorkBook.

Local Reconstruction

Local reconstruction transforms the digitized hits from the tracker into reconstructed hits in the local coordinate system of the silicon sensors. This is performed in two stages:

• Clustering: forming clusters of adjacent pixels or strips above threshold
• RecHit conversion: giving the reconstructed hit position with the errors

The reconstructed hits are needed as input for the Track Reconstruction.

Looking into CMS.RecoLocalTracker_cff.py you can find several sequences:

sequence pixeltrackerlocalreco = {siPixelClusters * siPixelRecHits}
sequence striptrackerlocalreco = {siStripZeroSuppression * siStripClusters * siStripMatchedRecHits}

sequence trackerlocalreco =  {pixeltrackerlocalreco * striptrackerlocalreco}

The first two sequences performs Local Reconstruction (Clusterization and RecHit Conversion) for the Pixels and for the Strips separately. The trackerlocalreco sequence gathers the previous ones and therefore is able to run Local Reconstruction for the whole Tracker.

The modules called in these sequences are included from the corresponding cfi file. For example siPixelClusters is included in the line:

from CMS.RecoLocalTracker.SiPixelClusterizer.SiPixelClusterizer_cfi import *

while siStripMatchedRecHits needs

from CMS.RecoLocalTracker.SiStripRecHitConverter.SiStripRecHitConverter_cfi import *
from CMS.RecoLocalTracker.SiStripRecHitConverter.SiStripRecHitMatcher_cfi import *
from CMS.RecoLocalTracker.SiStripRecHitConverter.StripCPEfromTrackAngle_cfi import *

The other includes are related to Geometry and Magnetic Filed services which are necessary for the Local Reconstruction process.

Track Reconstruction

The track reconstruction in CMSSW in done in four processes:

• the seed finding
• the pattern recognition
• the final fit
• collection cleaning and quality

The Track Reconstruction precesses are collected in RecoTracker_cff.py. It includes the iterative tracking sequence and the Road Search one. CMS.RoadSearch runs the four track reconstruction processes in one step only:

rstracks = cms.Sequence(roadSearchSeeds * roadSearchClouds * rsTrackCandidates * rsWithMaterialTracks)

The iterative tracking runs the four processes iteratively. At each step, the configuration of the four processes changes. Only the configuration for the first step is described below (FirstStep_cff.py). For the other steps, please read SWGuideIterativeTracking.

Seed Finding

The Seed Finding step is accomplished by the GlobalSeedsFromTriplets and GlobalSeedsFromPairsWithVertices modules for Iterative Tracking first step and roadSearchSeeds module for Road Search. They are included from GlobalSeedsFromTriplets_cff.py, GlobalSeedsFromPairsWithVertices_cff.py and RoadSearchSeeds_cff.py. Iterative tracking seeding use hits both from pixels and from strips to produce a seed, while roadSearchSeeds use only information from the strip detector.

Pattern Recognition

The Pattern Recongnition step is performed by the ckfTrackCandidates module for Iterative Tracking (included from CkfTrackCandidates_cff.py) and by two different modules (roadSearchClouds and rsTrackCandidates) for RS. These modules are included from:

from RecoTracker.RoadSearchCloudMaker.RoadSearchClouds_cff import *
from RecoTracker.RoadSearchTrackCandidateMaker.RoadSearchTrackCandidates_cff import *

Final Fit

The next step in the track reconstruction is the final fit. ctfWithMaterialTracks and rsWithMaterialTracks are the modules needed by the final fit for CTF and RS respectively. They are included from CTFFinalFitWithMaterial_cff.py and RSFinalFitWithMaterial_cff.py.

Track Cleaning and Quality

After the final fit, the ckf tracks are filtered in order to reject fake tracks and the tracks that pass the filter are labeled with a quality (see also SWGuideFinalTrackSelectors). The sequence is defined in TracksWithQuality_cff.py:

tracksWithQualityStepOne = cms.Sequence(firstStepWithLooseQuality*firstStepWithTightQuality*preMergingFirstStepTracksWithQuality)

These modules correspond to three quality labels: loose, tight and highPurity.

Iterative Tracking

Tracking in CMS follows an CMS.IterativeTracking approach. It can summarized as follows: the CTF track reconstruction process, defined above as made of seeding, pattern recognition, final fit and track cleaning, is performed n times iteratively. Each iteration is a step of the CMS.IterativeTracking. At the end of each step, the hits associated to high quality tracks are removed and the new reconstruction steps is performed with different (usually looser) algorithmic cuts.

How to run the Reconstruction Process

Most of the samples the user needs to analyze already contain the reconstructed tracks and there is no need to run a new track reconstruction process. Nevertheless, some users may need to customize tracking according to his/her use case. In this section it is shown how to re-reconstruct tracks with the default settings: the user needs to replace only the parameters he/she needs to overwrite.

Thanks to CMS.RecoLocalTracker_cff.py and RecoTracker_cff.py, editing a Configuration File to execute the Track Reconstruction processes is very easy.

Suppose you have a sample of events with raw data stored in a file called rawDataSample.root.

Then you just need to edit a Configuration File (say RecoTracks_cfg.py) and edit it as follows:

import FWCore.ParameterSet.Config as cms
process = cms.Process("RP")
process.load("Configuration.StandardSequences.Services_cff")
process.load("Configuration.StandardSequences.Geometry_cff")
process.load("Configuration.StandardSequences.MagneticField_cff")
process.load("CondCore.DBCommon.CondDBSetup_cfi")
process.load("Configuration.StandardSequences.FrontierConditions_CMS.GlobalTag_cff")
process.GlobalTag.globaltag = "IDEAL_31X::All" #use the correct tag for your data!
process.prefer("CMS.GlobalTag")
process.load("FWCore.MessageService.MessageLogger_cfi")
process.load("Configuration.StandardSequences.RawToDigi_cff")
process.load("RecoVertex.BeamSpotProducer.BeamSpot_cff")
process.load("Configuration.EventContent.EventContent_cff")

process.load("RecoLocalTracker.Configuration.RecoLocalTracker_cff")
process.load("RecoTracker.Configuration.RecoTracker_cff")

process.maxEvents = cms.untracked.PSet(input = cms.untracked.int32(-1))

process.source = cms.Source("PoolSource",
    catalog = cms.untracked.string('PoolFileCatalog.xml'),
    fileNames = cms.untracked.vstring('file:rawDataSample.root')
)

process.RECO = cms.OutputModule("PoolOutputModule",
    process.RECOSIMEventContent,
    fileName = cms.untracked.string('recoTracks.root')
)

process.p1 = cms.Path(process.RawToDigi*process.trackerlocalreco*process.offlineBeamSpot*process.ckftracks*process.rstracks)
process.outpath = cms.EndPath(process.RECO)

Executing

cmsRun RecoTracks_cfg.py

you perform the Local Reconstruction for both Pixels and Strips (trackerlocalreco) and reconstruct Tracks using both the CKF/Iterative (ckftracks) and the RS (rstracks) algorithms and store everything in a file called recoTracks.root. This process uses default settings for every module. For more information about FrontierConditions and BeamSpot, please look at SWGuideFrontierConditions and SWGuideFindingBeamSpot.

Using non-default settings

If, for example you wish to change one of these default settings and change the outlier rejection cut from the default value of 20 to 25, just add the following line in the RecoTracks_cfg.py file after process.load("RecoTracker.Configuration.RecoTracker_cff"):

process.KFFittingSmootherWithOutliersRejectionAndRK.cut = cms.double(25.0)

---

Part Three (for experts only)

---

Refitting Tracks

Some use-cases require performing a new Final Fit over already reconstructed Tracks. For examples, for alignment studies, you can refit Tracks after having modified the geometry of detectors. Refitting tracks is also useful if you need access to their Trajectory.

The TrackRefitter class is responsible for this task: it takes as input a collection of reco::Tracks, and puts into the event a new TrackCollection containing refitted Tracks.

The only difference between a "standard" Final Fit and a Refit is the starting TrajectoryStateOnSurface. A TrackCandidate already stores a starting TSOS (i.e. a TSOS on the surface of the first hit) with enlarged errors on parameters to unbias the fit, while a reco::Track has lost this information. Therefore a new TSOS is built propagating the state of the Track at the impact point to the surface of the first hit and then rescaling errors. This new TSOS is very close to the one owned by the TrackCandidate: a proof is that running the Refitter with the same conditions (e.g. same geometry) of the first Final Fit the differences between any parameter of the produced Tracks are orders of magnitude smaller than the estimated errors on that parameter.

The name of the related module is TrackRefitter, defined in:
RecoTracker/TrackProducer/python/TrackRefitter_cfi.py.

In order to run it, just include process.load("RecoTracker.TrackProducer.TrackRefitters_cff") in your configuration file and add process.TrackRefitter to the path. An example is provided in:
RecoTracker/TrackProducer/test/TrackRefit.py.

By default, it not only stores the refitted tracks in the Event, but also their Trajectory.

For information about the refitting with constraints, have a look at: SWGuideRefitterWithConstraints.

Electron tracking and GSF

Electrons can be reconstructed with the algorithms described above, but they constitute a special case due to the highly non-Gaussian nature of their energy loss. An extension of the Kalman filter algorithm has been developped for these cases: the Gaussian Sum Filter. Instead of using only the mean and the standard deviation it describes the energy loss spectrum by a weighted sum of Gaussians, representing different hypotheses ranging from low to high radiation. This description is more precise, but the fit is considerably slower. The result contains more information than a simple parameter vector and its covariance matrix: it is again a weighted sum of different states and therefore non-Gaussian. The following instructions are intended to show the different components available in the tracker, they aren't a recommended recipe for global electron reconstruction!

Seeding

For a first look at electrons in the tracker the standard globalPixel or globalMixed seeds can be used. Special seed collections can be created based on ECAL clusters (see the ElectronPhoton reconstruction).

Track Candidates

The CKF can be used to find electron candidates, but the modelling of the energy loss has to be changed and the Chi2-cuts used for hit association have to be loosened. An example of a configuration file can be found in TrackingTools/GsfTracking/data/CkfElectronCandidates.cfi . The difference to the standard CKF configuration is the use of the electron mass in the configuration of the propagators and a change in the Chi2-cut (you may want to loosen it even further). The result is a collection of CkfElectronCandidates.

KF fitting of electrons

In a similar way electrons can be fitted using a Kalman filter. An example can be found in TrackingTools/GsfTracking/data/FinalElectronFit.cfi . Again, the main difference w.r.t. the standard fit is the use of the electron mass in the propagator. The module will produce a collection of Tracks and TrackExtras named KfElectrons.

GSF fitting of electrons

In order to be able to store the additional information provided by the GSF a new Track class has been created: reco::GsfTrack. It can contain a reference to reco::GsfTrackExtra. Its interface is equal to the one of reco::Track : the track parameters correspond to a single state, derived from the weighted average of the Gaussian sum. The inner and outer states in GsfTrackExtra are defined in a similar way. The difference w.r.t. TrackExtra are the new methods for access to the Gaussian sum, defined in local co-ordinates at the innermost or outermost hit:

innerStateLocalPzSign	sign of momentum . normal_vector_to_surface
innerStateWeights	weight / component
innerStateLocalParameters	local parameter vector / component
innerStateLocalCovariances	covariance matrix (local system) / component

and the same for the outerState. A helper class is available to convert this information into a TrajectoryStateOnSurface : TrackingTools/GsfTools/interface/MultiTrajectoryStateTransform.h .

An example of a configuration for a GSF electron fit can be found in TrackingTools/GsfTracking/data/GsfElectronFit.cfi. The module will produce a collection of GsfTracks and GsfTrackExtras named GsfElectrons.

Regional & Partial Tracking (for HLT)

For HLT, it is desirable to reconstruct tracks only in selected windows around jets, rather than globally for the entire event. To speed things up even further, one can partially reconstruct these tracks, stopping after a desired number of hits have been assigned to them.

This requires some changes to the .cfg file, compared with global track reconstruction. An example .cfg file that does regional tracking can be found in RecoTracker/CkfPatter/test/regionalTracking.cfg. It includes: RecoTracker/TkSeedGenerator/data/RegionalPixelSeeds.cfi. The parameters in this file specify:

1. The collection of jets around which regional tracking will be performed. (If you only wish to do it on a subset of the jets in the event, you will need to create this yourself). And the size of the eta-phi window placed around each jet.
2. The collection of primary vertices from which the tracks are assumed to have originated. And the size of the tolerance cylinder placed around each of these vertices.
3. The minimum Pt of tracks.

One must request that track candidates be formed starting from these seeds:

include "/RecoTracker/CkfPattern/data/CkfTrackCandidates.cff"
replace ckfTrackCandidates.SeedProducer = "regionalPixelSeedGenerator"

and limit the number of hits assigned to the track by the trajectory builder:

include "RecoTracker/CkfPattern/data/CkfTrajectoryBuilderESProducer.cff"
replace !CkfTrajectoryBuilder.maxNumberOfHits  = 7

Accessing the hit pattern of a track

Please look at: WorkBookTrackAnalysis#HitPattern

How to access the track trajectory at each Tracker layer

Please look at: WorkBookTrackAnalysis#TrajLay

Accessing the track parameters at any point in space.

Please look at: WorkBookTrackAnalysis#TransTrack

Review status

Reviewer/Editor and Date (copy from screen)	Comments
GiuseppeCerati - 29 Apr 2009	Documentation Review
GiuseppeCerati - 17 Jun 2008	Update to CMSSW20X
GiuseppeCerati - 23 Jan 2008	Moved from old WorkBookTrackReco page

Responsible: GiuseppeCerati
Last reviewed by: IanTomalin - 22 Nov 2006