Persistent classes for Track Reco data format.
The complete track information is stored in two different object: reco::Track and reco::TrackExtra , that are stored in two different collection, physically written to fine into two different ROOT branches. This modularity allows the freedom to "drop" the reco::TrackExtra component, if not needed, and leave only reco::Track , in order to save disk space. This could be done, for instance while writing only the AOD component of a RECO collection.
A reco::Track has a reference ( edm::Ref ) to a reco::TrackExtra object that allows to access the information in the "extra" tier. Users don't necessarily have to dereference this persistent reference, since reco::Track has two sets of methods:
For instance, the following methods will only access reco::TrackBase data members:
reco::Track trk; double pt = trk.pt(); double eta = trk.eta();The following instead access data members contained in reco::TrackExtra :
reco::Track trk; double outerPt = trk.outerPt(); math::XYZPoint p = trk.outerPosition();and are equivalent to:
reco::Track trk; const reco::TrackExtraRef & trkExtra = trk.extra(); double outerPt = trkExtra.outerPt(); math::XYZPoint p = trkExtra.outerPosition();
Track helix parametrization follows the perigee model described in the internal CMS note CMS IN-2003/008 . The five parameters are:
The five parameters are stored internally in a vector whose index varies from 0 to 4, in the order listed above. The indices are also defined as the enumerator
index
defined in the namespace reco::helix:
enum index { i_transverseCurvature = 0 , i_theta, i_phi0, i_d0, i_dz };
So, for instance, in order to access specific track parameters a user can write the following code that requires no explicit numeric index:
using namespace reco::perigee; reco::TrackRef track = ... ; double d0 = track->parameter( i_d0 ); double covThetaPhi = track->covariance( i_theta, i_phi0 );
None.
None.
To be reviewed.
Last updated: @ L. Lista, Th. Speer