Heavy Ion Primary Vertex Reconstruction

Complete: 5

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

The code lives in the package 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.

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

One can generate the pixel prototracks and run the full vertex reconstruction chain from the following configuration file:

How to run the vertex reconstruction

If your events already have a VertexCollection called hiSelectedVertex, then the heavy ion vertex reconstruction has already been run, and you do not need to do it yourself. You can check this by either

  • opening the file in ROOT, opening a TBrowser, clicking on the Root file, then Events, and looking for a branch called something like recoVertexs_hiSelectedVertex__RECO., or
  • typing edmDumpEventContent filename.root at the command line, and searching for vector<reco::Vertex>     "hiSelectedVertex"    ""    "RECO." in the output.

If however your events don't contain this collection (e.g. you are generating your own Monte Carlo events) or you want to rerun the vertex reconstruction with different settings, follow the instructions below.

  • In your configuration file, include the lines

  • Then in the path in your configuration file, include the sequence hiPixelVertices

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

Note that the primary vertex algorithms are typically run as part of the tracking sequence described at SWGuideHeavyIonTrackReco#Running_the_track_reconstruction.


The heavy ion vertex reconstruction algorithms require a pixel prototrack collection as 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

Parameter settings in the vertex reconstruction algorithms should not, in general, need changing.

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).


The output of the heavy ion vertex reconstruction is a collection of reco::Vertex objects, which are identical in structure to the vertex collections produced in proton-proton events. The hiSelectedVertex collection will contain one and only one vertex object.

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

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


// Get reconstructed vertices
edm::Handle<reco::VertexCollection> 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:

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:

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:

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):

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

Review status

Reviewer/Editor and Date Comments
EdWenger - 19 Nov 2009 brought text up-to-date with status as of CMSSW 340
EdWenger - 20 Aug 2009 created page as part of documentation reviews

Responsible: EdWenger

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r3 - 2009-11-19 - EdWenger
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback