7.2 Track Analysis

Complete:
Detailed Review status

Goals of this page

This tutorial is intended to show the possible methods to access and analyze the reconstructed Tracks.

NOTE BENE: We will access track information in miniAOD files. Please, check the tracks information stored in the miniAOD.

NOTE: this twiki is under review in this moment.

Contents

• Finding Data Samples
• Access to Tracks
• Bare ROOT
• FWLite mode
• EDAnalyzer mode
• Physics Example
• Selecting Good Quality Tracks
• Advanced Analysis
  • Accessing track impact parameters
  • Accessing the hit pattern of a track
  • Accessing the track trajectory at each detector layer
  • Accessing the track trajectory at any point in space
  • Add more histograms with impact parameters and number of hits
• Review status

Finding data samples

Typically the user wishes to analyze an already generated and reconstructed sample: for example you may want to analyze tracks in CMS.ReleaseValidation or in officially produced physics samples. To find out these samples, please refer to the WorkBook Locating Data Samples section.

Access to Tracks

CMSSW provides three modes for the user to access event data in a CMSSW ROOT event file. Also for accessing the tracks, you can use one of the following modes (described in Analysis Methods).

• bare ROOT mode
• FWLite mode (loading the CMS.DataFormat libraries)
• Framework mode (using an EDAnalyzer module in a configuration file)

We will present an introduction to using tracks for analyses using miniAOD samples. Our exercises will all use real data. First of all you have to create the development area for the analyzer:

source /cvmfs/cms.cern.ch/cmsset_default.sh 
export SCRAM_ARCH=slc6_amd64_gcc530
cmsrel CMSSW_9_2_10
cd CMSSW_9_2_10/src/
cmsenv
voms-proxy-init -voms cms -valid 192:00

Bare ROOT

After opening a CMSSW ROOT file produced by the track reconstruction with Bare ROOT (no setup is needed, ignore all given warnings about missing dictionaries)

root recoTracks.root

and opening a TBrowser

TBrowser b;

you can see the different collections of objects in the ROOT file. A double click on the ROOT Files folder in the right window of the TBrowser and a following double click on the filename recoTracks.root shows the top branch level of the ROOT file. The collections are contained in the Events branch and are visible after double clicking it in the right window. The final track collections start with recoTracks.

With double clicks on a collection (for example the track collection: recoTracks_generalTracks__RECO and a subsequent double click on the Object branch in the collection recoTracks_generalTracks__RECO.obj, you can select single data members of the object in the collection and produce simple plots using the information of all events in the file by double clicking on a data member (for example recoTracks_generalTracks__RECO.obj.chi2_ to plot the track chi2 distribution).

Alternatively, type the Draw command for the main Events branch with the full name of the data member in the root command line:

Events->Draw("recoTracks_generalTracks__RECO.obj.chi2_")

This will produce the same plot of the track chi2 distribution as produced before with the TBrowser.

FWLite mode

More sophisticated analysis possibilities are offered by the FWLite mode which has access to all class dictionaries contained in a CMSSW ROOT file. The reprocessing of data, however, is not possible in the FWLite mode, this can be done through an EDAnalyzer module block and running cmsRun executable.

As example for the FWLite mode you can use next macro:

from DataFormats.FWLite import Handle, Events
import ROOT
#events = Events('root://cms-xrd-global.cern.ch//store/data/Run2017B/Charmonium/MINIAOD/PromptReco-v1/000/297/046/00000/88DF6C6A-4556-E711-A5C0-02163E01A630.root')
events = Events('myfile.root')
tracks = Handle("std::vector")

histogram = ROOT.TH1F("histogram", "histogram", 100, 0, 100)

i = 0
for event in events:
    print "Event", i
    event.getByLabel("packedPFCandidates", tracks)
    j = 0
    for track in tracks.product():
        print "    Track", j, track.charge() / track.pt(), track.phi(), track.eta(), track.dxy(), track.dz()
        histogram.Fill(track.pt())
        j += 1
    i += 1
    if i >= 5: break


c = ROOT.TCanvas ( "c" , "c" , 800, 800 )
c.cd()
histogram.Draw()
c.SaveAs("PtFW.png")

The name of the macro is " FWlite_analize_MiniAOD.py", this simply tells the FWlite to use as input file myfile.root (there is a example, you can use any file containing reconstructed events). You can run it as:

python FWlite_analize_MiniAOD.py

It print some of the properties oft he tracks as: charge, pt(), phi, eta, dxy and dz, besides in this case displays the pT distribution found per track:

EDAnalyzer mode

The most powerful way to process and analyze CMSSW data is to create an EDAnalyzer. This let the user pull in analysis code modules by way of parameter sets (in the form of configuration files), and running the cmsRun executable on the given parameter set thereby creating or modifying event data. This process exploits the full framework.

To create a very simple example af EDAnalyzer follow the instructions given this section (for more details go to the dedicated part of the workbook: WorkBookWriteFrameworkModule).

First of all you have to create the development area for the analyzer:

mkdir Demo
cd Demo
mkedanlzr DemoTrackAnalyzer
cd DemoTrackAnalyzer/src

In this directory you find DemoTrackAnalyzer.cc, an empty track analyzer which needs to be edited. Open it with your favorite editor.
Here it is shown how to produce the plot of transverse momentum distribution.

1. Under the comment //user include files add the following lines to include ROOT classes and the TrackCollection:
   • #include "DataFormats/PatCandidates/interface/PackedCandidate.h"
   • #include "FWCore/ServiceRegistry/interface/Service.h"
   • #include "CommonTools/UtilAlgos/interface/TFileService.h"
2. Add as private members a root file object and a pointer to a histogram:
   • edm::EDGetTokenT<edm::View<pat::PackedCandidate>> trackTags_;
   • TH1D * histo;
3. In the constructors, add output root file (TFileService)and book the histogram (Note ":" colon at the end of .....iConfig)):
   • trackTags_(consumes<edm::View<pat::PackedCandidate>>(iConfig.getParameter<edm::InputTag>("tracks")))
   • edm::Service<TFileService> fs;
   • histo = fs->make<TH1D>("pt" , "Pt" , 50 , 0 , 50 );
4. In the analyze method, inside the loop over the tracks in the TrackCollection, fill the histogram with the pt value of the track:
   • histo->Fill(itTrack->pt());

Your file should now look like this: DemoTrackAnalyzer_MiniAOD.cc
Save DemoTrackAnalyzer.cc. Before compiling it you need to edit the CMS.BuildFile. Add the following line on the top of the CMS.BuildFile:

<use name="root"/>
<use name="DataFormats/TrackReco"/>
<use name="CommonTools/UtilAlgos"/>
<use name="PhysicsTools/UtilAlgos"/>

Now compile:

cd ..
scramv1 b

In order to run the analyzer you need a configuration file. Using you editor, create a file called DemoTrackAnalyzer_cfg.py in the test directory and edit it as follows (for more details about configuration files: SWGuideAboutPythonConfigFile):

import ParameterSet.Config as cms
process = cms.Process("Demo")
process.maxEvents = cms.untracked.PSet( input = cms.untracked.int32(-1) )
process.load('FWCore.MessageService.MessageLogger_cfi')
process.MessageLogger.cerr.FwkReport.reportEvery = 10
process.options = cms.untracked.PSet( wantSummary = cms.untracked.bool(True) )
process.maxEvents = cms.untracked.PSet(input = cms.untracked.int32(-1))
process.source = cms.Source("PoolSource",
# replace 'myfile.root' with the source file you want to use
fileNames = cms.untracked.vstring(
'file:myfile.root'
)
)

process.demo = cms.EDAnalyzer('DemoTrackAnalyzer',
tracks = cms.InputTag("packedPFCandidates"),
)

process.TFileService = cms.Service("TFileService",
fileName = cms.string('outfile.root')
)

process.p = cms.Path(process.demo)

This configuration file simply tells the Framework to use as input file myfile.root (you can use any file containing reconstructed events) and to run the DemoTrackAnalyzer, using the CMS default TrackCollection (i.e. the collection labelled as PackedCandidate). Now we are ready to run the analyzer:

cd test
cmsRun DemoTrackAnalyzer_.cfg

This command will produce in the test directory a file called outfile.root. You can open it with ROOT:

root outfile.root

In ROOT open a TBrowser

TBrowser b;

A double click on the ROOT Files folder in the right window of the TBrowser and a following double click on the filename outfile.root shows the list of plots contained in the file. You should find only a plot called pt. Double click on it to display the pt distribution.This distribution should look like the one shown for the Bare ROOT Analysis.

Physics Example

The example uses this macro:

 Demo/DemoAnalyzer/plugins/miniAODmuons.cc

A physics process Jpsi->2mu can be analyzed in EdAnalyzer mode after starting in a completely setup local CMSSW project directory.

source /cvmfs/cms.cern.ch/cmsset_default.sh 
export SCRAM_ARCH=slc6_amd64_gcc530
cmsrel CMSSW_9_2_10
cd CMSSW_9_2_10/src/
cp -r /afs/cern.ch/user/j/jmejiagu/public/miniAODmuonexample/CMSSW_9_2_10/src/Demo/ .
cmsenv
voms-proxy-init -voms cms -valid 192:00
scram b -j8
cd DemoAnalyzer/test
cmsRun miniAODmuonsRootupler.py

We assume the reconstructed data sample to be stored in a file called Rootuple_JpsiToMuMu_2017-MiniAOD.root; otherwise, you should change the name of the output file in miniAODmuonsRootupler.py. Open ROOT:

root -l Rootuple_JpsiToMuMu_2017-MiniAOD.root

Then, to draw the Jpsi mass peaks, execute opening a TBrowser:

TBrowser b;

you can see the collections of object in the ROOT file. A double click on the ROOT Files folder in the right window of the TBrowser and a following double click on the filename Rootuple_JpsiToMuMu_2017-MiniAOD.root shows the branch ntuple. After double clicking it in the ntuple and double clicking B_J_mass:

You can see the Jpsi peak in the di-mu invariant mass distribution

Selecting Good Quality Tracks

Note: we will let this section as it is for didactic purposes, because there are still AOD samples. However, the only flag stored in MiniAOD (PackedCandidate) is "highPurity". Also PackedCandidate have others options, please chek here.

The "generalTrack" collection is produced using rather loose track finding cuts. As a result, it has a very high efficiency to find tracks, but it contains quite a large fraction of fake tracks. Therefore, most people doing physics analysis should use only a subset of the tracks that satisfy quality criteria. The simplest way of doing this, is to use the "quality" flag stored in the Track class. For example:

// Accept only good quality tracks. (This is suitable for most physics analyses)
if (track->quality(Track::highPurity)) { ... track ok ...}

// Accept either medium or good quality tracks. (if want very high efficiency and willing to accept some fakes)
// Note that "highPurity" tracks are a subset of "tight" tracks
if (track->quality(Track::tight)) { ... track ok ...}

// Accept poor, medium or good quality tracks. (if want extremely high efficiency and willing to accept many fakes)
// Note that "highPurity" and "tight" tracks are subsets of "loose" tracks
if (track->quality(Track::loose) { ... track ok ...}

The quality flag is based upon things like the number of hits on the track, its chi2 etc. as described here. You will probably also want to cut yourself on the track impact parameter and Pt. A convenient way of selecting tracks is to use the recoTrack selection tools.

(N.B. Historically, flags "goodIterative" and "confirmed" were also defined. However, these are now redundant and should no longer be used).

Advanced Analysis

Accessing track impact parameters

Track impact parameters with respect to the primary vertex (or any other vertex) can be obtained with reasonable precision via Track::dxy(vertex) ( = transverse impact parameter) and Track::dz(vertex) (=longtitudinal impact parameter). The corresponding errors can be obtained from Track::d0Error() and Track::dzError().

If the "reference point" about which the track parameters was evaluated is a long way from this vertex, then a more precise method is needed. Information on how to use this is given here here. This is not usually necessary for Tracker tracks, except for precision vertexing or b tagging.

Nota bene: if you want to use dxy or dz you need to be sure the pt of the tracks is bigger than 0.5 GeV, otherwise you will get an error related to covariance matrix. next lines are very recommended

if(itTrack->pt()<=0.5)continue;
if(itTrack->charge()==0) continue;// NO neutral objects
if(fabs(itTrack->pdgId())!=211) continue;//Due to the lack of the particle ID all the tracks for cms are pions(ID==211)
if(!(itTrack->trackHighPurity())) continue;

Accessing the hit pattern of a track

Note: please be carefully. From MiniAOD link you will se the next comment:
"approximate hitPattern() and trackerExpectedHitsInner() that yield the correct number of hits, pixel hits and the information returned by lostInnerHits()
(but nothing more, so e.g. you can't rely on methods counting layers, or expected outer hits, or lost hits within the track) "

Given a track (itTrack in our example), here is an example usage of hit pattern accessing the number of the hits and number of hits in the pixel:

// count the number of valid tracker *** hits ***
std::cout << "number of valid tracker hits is "
          << itTrack->numberOfHits() << std::endl;

// count the number of valid pixel *** hits ***
std::cout << "number of valid pixel hits is "
          << itTrack->numberOfPixelHits() << std::endl;

For more methods, please see DataFormats/TrackReco/interface/HitPattern.h.

How to access the track trajectory at each Tracker layer

This can be done exactly on RECO and approximately on AOD. The recipes differ, as explained below.

If you are using RECO, then you can access the track trajectory at its innermost and outermost hit very easily, using for example, Track::innerPosition() or Track::innerHit(). (These return the position and 3-momentum of the track at its point of closest approach to the innermost hit).

You may want to access track's parameters (i.e. its complete TrajectoryMeasurement) on the surface of every layer crossed by the track. The trajectory is the object devoted to collect all the TrajectoryMeasurements (TM) of the tracks. Nevertheless, due to its size on disk, the trajectory cannot be saved on the RECO data file and, after the final fit of the tracks is done, the informations about the TMs were discarded. Final Track contain only the TSOS on the innermost and outermost hits. However, you can refit the tracks in RECO, and this will recover their trajectory information, so solving the problem.

Information on how to refit tracks can be found here.

For MiniAOD the information is very reduce.
Inner hit information: lostInnerHits() will return -1 (validHitInFirstPixelBarrelLayer) if the track has a valid hit in the first pixel barrel layer, 0 (noLostInnerHits) if it doesn't have such hit because of geometrical or detector inefficiencies (i.e. the hit wasn't expected to be there), 1 (oneLostHit) if the track extrapolation towards the beamline crosses an active detector but no hit is found there, 2 (moreLostHits) if there are at least two missing expected inner hits.

Accessing the track parameters at any point in space using TransientTracks.

TransientTracks can be created from normal reco::Tracks. They allow one to extrapolate the track to any point in space. This is useful for vertex reconstruction and for b/tau tagging. For more details about this topic please visit SWGuideTransientTracks.

Add more histograms with impact parameters and number of hits

I will not go into detail about how you should add more histograms. This is the file " DemoTrackAnalyzer_MiniAODnew.cc" that you have to change to plot more histograms. Compare it to what you already have and make changes by seeing what is missing. In this new file there are some comments wichs you could found very helpful.

You could found all the examples in the next github link.

Review status