Heavy Ion Primary Vertex Reconstruction

Goal of this page

The aim of this page is to document the primary vertex reconstruction used in heavy ion events—where the code lives, how to run it, the input and output, and details of the implementation.

Code and tags

RecoHI/HiTracking

The full feature set described on this page is for the CMSSW 34X release series. For earlier releases, one can try to access these features with varying success based on the instructions below.

CMSSW 33X:
cvs co -r CMSSW_3_4_0_pre5 RecoHI/HiTracking cvs co -r CMSSW_3_4_0_pre5 RecoPixelVertexing/PixelTrackFitting

CMSSW 31X and 32X:
The full feature set is not completely supported in these versions, but if really necessary one can try the recipes contained in: UserCode/CmsHi/Utilities/scripts/setup33X_reco.sh or setup3XY.sh

Configuration files

RecoHI/HiTracking/python/HIPixelVertices_cff.py

How to run the vertex reconstruction

Do you need to run the vertex reconstruction? Hide

Running the vertex reconstruction only... Hide

process.load("RecoHI.HiTracking.HIPixelVertices_cff.py")

Input

Product type	Module label
vector<reco::Track>	hiPixel3ProtoTracks

Reconstructing such pixel tracks requires the presence of silicon pixel digis. If it does not find these in the event the reconstruction will crash.

Product type	Module label
edm::DetSetVector<PixelDigi>	siPixelDigis
edm::DetSetVector<SiStripRawDigi>	siStripDigis

Parameter settings

One exception might be an improved tuning of the parameterized relation between first-layer pixel hits and charged particles that ensures the vertexing algorithm uses a consistent number of input tracks regardless of event centrality (multiplicity).

Output

reco::Vertex

Accessing the vertex information

Vertex information can be accessed in the same fashion as described in the WorkBookOfflinePrimaryVertexFinding.

As always, the Validation subsystem is a good resource for finding what can be done with reconstruction objects e.g. Validation/RecoVertex/src/CMS.PrimaryVertexAnalyzer.cc

Another example is given in UserCode/CmsHi/TrackAnalysis/VtxAnalyzer.cc

Show more details... Hide

#include "DataFormats/VertexReco/interface/Vertex.h"
#include "DataFormats/VertexReco/interface/VertexFwd.h"

...

// Get reconstructed vertices
edm::Handle<reco::VertexCollection> vertexCollection;
iEvent.getByLabel("hiPixelAdaptiveVertex",vertexCollection);
const reco::VertexCollection * vertices = vertexCollection.product();

std::cout << "The z-position of the first vertex in the collection is " << vertices->begin()->z() << std::endl;

Implementation details

Configuration fragments:

As currently implemented, the heavy ion vertex reconstruction uses two separate algorithms in sequence. The first is a quick but less precise 1-d vertex algorithm with which to make a selection on the input prototracks that are passed to the slower but more precise 3-d vertex algorithm:

• HIPixelMedianVertex_cfi.py
• HIPixelAdaptiveVertex_cfi.py

Each algorithm requires pixel prototracks as input. The first input collection is generated using the following configuration, which implements the multiplicity-dependent restricted tracking region. In central HI collisions the tracking region is reduced in eta and phi such that a constant number of primary tracks are passed to the median vertex algorithm. Similarly, in peripheral collisions the minimum pt of the tracking region is variably reduced to maintain a minimum number of prototracks:

• HIPixel3ProtoTracks_cfi.py

The input to the precise vertex algorithm is a subset of the above prototracks that are selected with the following configuration based on their z-vertex compatibility to the median vertex and their transverse compatibility to the beamspot:

• HISelectedProtoTracks_cfi.py

Finally, a single vertex is chosen as the best choice primary vertex. (Note that pileup is expected to be negligible during HI running). Currently, the 3-d vertex with the most associated tracks is used, unless the algorithm fails (e.g. not enough prototracks). In case of failure the 1-d vertex is used for the z-position and beamspot for the transverse location. If no prototracks are reconstructed, the beamspot is used. In all cases, the relevant errors on the vertex position are propagated to the "selected" vertex. In the future, other methods can be added to this selection to retrieve better performance in the extreme low-multiplicity case (e.g. tracklet-based or cluster-based vertexing):

• HISelectedVertex_cfi.py

Source code:

• HIPixelMedianVtxProducer.cc - median vertex algorithm
  • Simple histogramming method to find the z-position of the interaction point based on pixel tracks.
  • The median z-position of the input pixel tracks is selected and a Gaussian-plus-constant is fitted to find the most likely vertex.
  • For very high pixel track multiplicities, the fit is done about the maximum bin rather than the median; for very low pixel track the median is simply selected without the fitting step.

• PrimaryVertexProducer.cc - adaptive vertex fitter
  • Offline vertex reconstruction code that takes a vertexing algorithm (e.g. AdaptiveVertexFitter) as an argument.
  • Typically used with full tracks, but in our implementation we pass it pixel tracks, modifying a few parameters accordingly.

• HITrackingRegionForPrimaryVtxProducer.h - restricted tracking region
  • Estimate the number of primary charged particles based on first-layer pixel hits
  • If this value is above a threshold, define a RectangularEtaPhiTrackingRegion with the Δη restricted so as to contain ~100 primary tracks
  • Below the threshold, a GlobalTrackingRegion is used, with the PtMin dropping from 1.0 to 0.075 GeV/c depending on the first-layer pixel hit multiplicity as well.

Further information

• More information is available from the main offline vertex reconstruction page: SWGuideVertexReco
• External page detailing performance of the algorithm

Review status

Responsible: EdWenger