Heavy Ion Primary Vertex Reconstruction
Complete:
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.
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
One can generate the pixel prototracks and run the full vertex reconstruction chain from the following configuration file:
RecoHI/HiTracking/python/HIPixelVertices_cff.py
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
process.load("RecoHI.HiTracking.HIPixelVertices_cff.py")
- 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.
Input
The heavy ion vertex reconstruction algorithms require a pixel prototrack collection as input:
Reconstructing such pixel tracks requires the presence of silicon pixel digis. If it does not find these in the event the reconstruction will crash.
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).
Output
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;
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:
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
Responsible:
EdWenger