genfitgenfit.sourceforge.net/genfit_v1_2.pdf · 1genfit - a generic toolkit for track...

GENFIT

a Generic Track Reconstruction Toolkit(v1.2)

Christian Höppner, Sebastian Neubert,Bernhard Ketzer & Stephan Paul

Technische Universität München, Physik-Department

Author of this memo: Christian Höppner, Technische Universität München

A future version of this memo is to be published as a chapter of my PHD thesis in 2010.Please do not circulate it outside of the PANDA collaboration.

June 2009

Chapter 1

GENFIT - a Generic Toolkit for TrackReconstruction

Spectrometers in high energy nuclear physics have the purpose of identifying the 4-momenta ofparticles stemming from high-energy collisions and decays of particles or nuclei. Besides calori-metric and other particle identification measurements, these detector systems achieve this by mea-suring the 3-momenta of charged particles, by tracking them in magnetic fields. The responses ofa combination of position sensitive ionization detectors serve as the input for a fitting algorithmwhich determines the best estimates for the particles’ momenta at any point along their trajectories,most importantly at the particles’ creation vertices.

Various species of particle detectors are usually used in combination with each other. They areclassified here according to their different geometrical requirements to the reconstruction algo-rithm:

• Strip detectors deliver the position of particle passage along a well defined axis in the de-tector plane. Examples are silicon strip detectors, micro-pattern gaseous detectors with stripreadout, or wire chambers.

• Pixel detectors deliver two dimensional information, i.e. the penetration point of a trackthrough the detector plane. Examples are the same as for the strip detectors, but of coursewith a pixelized readout structure.

• Wire-based drift detectors deliver their wire position and a drift time, i.e. a surface ofconstant drift time around the wire through which the particle passed tangentially.

• Time projection chambers measure three-dimensional space points along the particle trajec-tories.

The track fitting software in many experiments resorts to more or less justified simplifications forthe latter two categories or any kind of detectors which do not deliver tracking information in anactual physical detector plane. Examples are the fitting of TPC data in pad rows or the treatmentof data from drift cell detectors as two lines, just leaving a right-left ambiguity. The latter is

1

1 GENFIT - A GENERIC TOOLKIT FOR TRACK RECONSTRUCTION

especially problematic if the drift cells are not arranged in a planar configuration and if there is nopreferred direction in which the tubes are passed by the particles.But even for planar detectors which deliver two-dimensional information, like Silicon pixels, itis not uncommon to treat one 2-D measurement as two independent 1-D measurements, which isstatistically questionable.

GENFIT has been designed to overcome these problems. In this toolkit the dimensionality ofdetector hits is not restricted. One-dimensional hits constrain the track only along the coordinateaxis which they measure. Two-dimensional hits are used in one fitting step to constrain the trackin two dimensions their its detector plane. Other hits like drift tubes or three-dimensional spacepoints from a TPC are treated in the concept of so-called virtual detector planes. These are detectorplanes which are calculated dynamically for every extrapolation of a track to a hit. They convertthe hit information (could e.g. be a drift time) into a position measurement in a plane perpendicularto the track. This leads to a fit which minimizes the perpendicular distances of the track to thedetector measurements, i.e. a χ2-minimization. The special nature of hits with virtual detectorplanes is completely hidden from the fitting algorithm.But even higher hit dimensionalities are treated correctly in GENFIT. If a detector system forinstance measures the penetration point of a trajectory in a plane and its local direction in theplane, this full information can be used in one four-dimensional reconstruction hit, taking intoaccount all correlations.

This software package has also been designed to handle different track models with differentpropagation mechanisms and track parametrizations, even within the same event. This flexibilityis especially useful in the early phase of an experiment when different track following approachescould be compared with each other, in order to identify the ones with optimal performance in theparticular experiment. But also the flexible coverage of different phase space regions with differenttrack parametrization can be very beneficial.

GENFIT is not a complete track fitting package. It requires external code for the propagation ofparticles in magnetic fields and materials. It is on the other hand a toolkit that organizes trackfitting in a novel way. It completely decouples the algebra of the regression algorithm from therepresentation of hits and tracks. It enables the user to combine hits and tracks of very differentkinds with each other in the same fits. Due to the complete encapsulations and separation ofalgebra, hit representations, and track models, the user’s implementation of either one of thembecomes very simple. GENFIT contains a tested Kalman filter algorithm and several examples fordetector hit implementations.

GENFIT has been developed by Sebastian Neubert and myself at TU München in a fair 50-50effort, which I want to thank him for. It has been developed in the framework of the PANDA [1]experiment for TPC reconstruction, but quickly turned out to be a good tool for global tracking. Itis currently part of PANDAroot [2], which is the PANDA experiment’s computing framework, butit can easily be distributed as a stand-alone package.

2

Kalman Filter

1.1 Kalman Filter

In order to get an overview over all mechanisms that are required in this toolkit, it seems bestto start with a description of the regression algorithm, which is the central part of the fitter. TheKalman filter [3] is the common choice for this algorithm. Other fitting algorithms might beevaluated in the future, but so far only the Kalman filter has been implemented in GENFIT. Allnecessary variables and equations of Kalman filtering will be introduced in this section. Most ofthe literature on track fitting with Kalman filters lacks a proper derivation of the Kalman filterequations. Such a derivation is presented in appendix A.

The extended Kalman filter is an efficient recursive algorithm that finds the best estimate for thestate of dynamic systems from a series of noisy measurements. It has been applied to track fittingin high energy physics [4] by very many experiments. The state vector of the system xk (the indexk counts the hits in the detectors) is defined by the track parameters. One step of the algorithmis defined as the inclusion of the measurement information of one more hit k into a state vectorthat already contains the information of the all the hits up to k−1. Before the filter step, the statevector is given at the place of measurement of hit k−1. In the prediction step, the values of thestate vector and its covariance matrix are extrapolated to the place of measurement of hit k. Then,the algorithm calculates the update for the state vector and the covariance matrix such that thisfiltered track comes closer to the hit than the predicted one did. How much this hit can attractthe track towards itself, depends on the relative sizes of the covariance matrices of the hit and thetrack, and is mathematically expressed in form of the so-called Kalman gain. The entries of thecovariance matrix shrink with the inclusion of more hits, thus reducing the impact of single hitson the value of the state vector.

In GENFIT, measurements of detectors are always defined in detector planes. These can eitherbe physical detector planes or, in the case of non-planar detectors, virtual detector planes. Thissubject is discussed in detail in section 1.5. The situation which is assumed before the fit is thatone or several detectors have made measurements of the particle trajectory. These hits shall onlystem from one track and shall be sorted, at least to some extent. It is assumed that these tasks ofpattern recognition are done before GENFIT is used.

There are two important coordinate systems for the Kalman filter:

1. The coordinate system of measurements of a detector, which is defined by the two vectorswhich span the individual detector plane. If a detector measures other coordinates likedrift times, these are dynamically converted into the detector plane coordinates before theyare used in the fit. This results in either one- or two-dimensional measurement vectors,depending on how many coordinates the detector can constrain in the detector plane (e.g.a strip detector can only measure one coordinate). But also higher dimensional hits, whiche.g. additionally define a local direction of the track, are possible.The measurement vector of hit k is called mk.

2. The coordinate system of state vectors, which describe the state of tracks in a given detectorplane. These are usually five-dimensional vectors for particle tracking in magnetic fields,

3


which define the charge and magnitude of the 3-momentum of the particle (q/p), and the lo-cation and direction of the momentum vector with respect to a detector plane (2 coordinateseach). The symbol x̃k denotes the (of course always unknown) true value of the state vectorin the plane of hit k. The predicted and filtered state vectors are denoted by xk|k−1 and xk|k.

The only requirement to the choice of coordinates systems is that there must exist a linear trans-formation Hk which transforms state vectors into the coordinate system of the detector’s measure-ment, i.e. that mk and Hk · x̃k are in the same coordinate system.

The following table defines all parameters, quantities, and equations involved in Kalman filtering:

mk = Hkx̃k + vk Hit coordinates vector (can be one-dimensional). Hits arecounted with the index k.

x̃k The (unknown) true state vector.Hk Linear transformation from the vector space of state vec-

tors to the vector space of detector measurements, i.e. mkand Hk · x̃k are in the same coordinate system. The matrixhas the dimension dim(mk)×dim(x̃k).

vk Deviation or noise of the position measurement.Vk = Cov(vk) Covariance of measurement noise vk.

xk|k−1 Predicted state vector at the detector plane of hit k. Itcontains all information of the hits up to index k− 1 andis extrapolated from there. The extrapolation uses externaltrack following code.

Ck|k−1 = Cov(x̃k − xk|k−1) Predicted covariance matrix. It contains all informa-tion of the hits up to index k− 1 and is extrapolated fromthere, taking into account multiple scattering and energyloss straggling. The extrapolation uses external track fol-lowing code.

rk|k−1 = mk −Hkxk|k−1 Residual vector of the measurement and the extrapolatedtrack.

Rk = HkCk|k−1HTk +Vk Covariance of the residual, see appendix A for a derivation.Kk = Ck|k−1HTk R

−1k Optimal Kalman gain, see appendix A for a derivation.

xk|k = xk|k−1 +Kkrk|k−1 Updated state vector.Ck|k = (I−KkHk)Ck|k−1 Updated covariance matrix, with the identity matrix I.

See appendix A for a derivation.rk|k = mk −Hkxk|k Filtered residual vector.

χ2k = rTk|k(Vk −HkCk|kH

Tk )

−1rk|k χ2 of this hit.

Table 1.1: Definition of quantities and equations of the Kalman filter.

4

The Structure of GENFIT

GFKalman

list of

list of

polymorphicimplementation

through interfaceGFAbsRecoHit

realizedthrough

GFTrack

acts on

contains contains

polymorphicimplementation

through interfaceGFAbsTrackRep

realizedthrough

state vectorcovariance matrix

reference plane

hit coordinateshit covariance

eachcontain

eachcontain

Track Candidate

list of indices of hits which belong to the

track

contains

contains

createdfrom

Figure 1.1: General structure of GENFIT.

1.2 The Structure of GENFIT

The basic concept of GENFIT is that the class which represents the GFKalman filter operates onso-called GFTrack objects, which contain a list of reconstruction hits and a list of track repre-sentations. The reconstruction hits are created from the list of hits belonging to the track, whichis stored in the track candidate (see section 1.3). This principle is illustrated in figure 1.1. Thereconstruction hits are usually different for different detector systems and are accessed by theGFKalman class through the abstract interface class GFAbsRecoHit. This class holds the hit co-ordinates and the hit covariance matrix. The track representations are derived from an abstractinterface class called GFAbsTrackRep, which contains the state vector, the track covariance ma-trix, and the reference plane at which the state vector and its covariance matrix are defined. Thetrack representations are the interfaces to external track extrapolation packages. GENFIT doesnot contain track extrapolation code. All vectors and matrices are implemented using ROOT’s [5]TMatrixT class.GENFIT offers the possibility to use several GFAbsTrackReps to describe the same track in orderto fit different particle hypotheses (usually proton, pion, muon, kaon, and electron) or to try dif-ferent track parametrizations in regions of phase space in which it is not clear which one will givebetter results. The simple interchangeability of track representations is also very useful in the earlyphase of an experiment where one needs to develop and evaluate different track parametrizationsand propagation codes to find an optimal compromise between resolution and performance.

After setting up the GFTrack object to contain the GFAbsRecoHits and correctlyinitialized GFAbsTrackReps, the user of the Kalman filter just calls the methodGFKalman::processTrack(GFTrack*) to perform the fit. This method performs several fit-ting passes along the track. It performs the Kalman filter steps for all GFAbsRecoHits on allGFAbsTrackReps, first in the forward direction (assuming forward sorting), and then once again

5


Kalman

Reco Hit Track Representation

track parameters and covariances

reference plane

hit coordinates and coviariance

update

reconstructed cluster

residual extrapolation to hit position

contains contains

calculates

calculates

input

provides

modifies

initializes

input

detector plane

for planar: returnsfor non-planar: calulateswith help from track rep.

input

external track propagation

package

uses

Figure 1.2: Distribution of responsibilities for a Kalman step.

in backward direction. The track is then defined at the plane of the first hit after one forward-backward fitting iteration. Several of these iterations can be performed to further minimize thebias due to the poor knowledge of the track parameters before the fit, which is not fully eliminatedafter just one forward pass of Kalman filtering. The covariance matrix must be reset to containlarge values after each fitting pass (the diagonal elements are multiplied with a large factor, and theoff-diagonal elements are set to zero), otherwise the magnitude of the track errors would shrinkwith the inverse square root of the number of fitting passes.

One Kalman step as defined inprivate : void GFKalman::processHit(GFAbsRecoHit* hit, GFAbsTrackRep* rep)updates the state vector and covariance matrix of one GFAbsTrackRep to contain the informationof one more GFAbsRecoHit. Figure 1.2 gives an overview over this process and is best studiedtogether with the following detailed description. The GFKalman::processHit(...) methodproceeds as follows:

• Get the detector plane (instance of class GFDetPlane) by callingGFAbsRecoHit::getDetPlane(GFAbsTrackRep*), which will return either thephysical detector plane for a planar detector (e.g. a silicon detector), or a virtual detectorplane for non-planar detector (e.g. a TPC). For the calculation of the virtual detector planethe GFAbsTrackRep is needed (usually to find the point of closest approach). For detailssee section 1.5.1.1.

• The track is extrapolated to this detector plane to obtain the predictions of state vector andcovariance matrix, xk|k−1 and Ck|k−1.

6

The Structure of GENFIT

• The hit covariance Vk is acquired by calling GFAbsRecoHit::getHitCov(GFDetPlane&),which transforms the raw hit covariance information into the specific detector-plane coor-dinate system. The raw covariance would e.g. contain position resolutions or a drift timeresolution.

• The matrix Hk is obtained by callingGFAbsRecoHit::getHMatrix(GFAbsTrackRep*). A C++ dynamic cast is used to de-termine of which concrete type the track representation is. This is necessary because thelinear transformation matrix Hk depends on the concrete choice of coordinate system forthe state vectors and covariance matrices. This is especially important if two different trackrepresentations are used to fit the same track. This mechanism also ensures the compatibil-ity between hits and state vectors1. An example implementation of this method is given insection 1.5.

• The Kalman gain Kk is calculated: Kk = Ck|k−1HTk (HkCk|k−1HTk +Vk)−1.

• The residual vector rk|k−1 = mk −Hkxk|k−1 is calculated by callingTMatrixT GFAbsRecoHit::residualVector(const GFAbsTrackRep*,

const TMatrixT&, const GFDetPlane&).

• The state vector, the covariance matrix, and the reference plane of the GFAbsTrackRep areupdated: xk|k = xk|k−1 +Kkrk|k−1 and Ck|k = (I−KkHk)Ck|k−1.

• The χ2-increment is calculated as χ2k = rTk|k(Vk −HkCk|kHTk )

−1rk|k with the filtered residualrk|k = mk −Hkxk|k. It is then saved to GFAbsTrackRep together with the number of degreesof freedom contributed by this GFAbsRecoHit, which can be different for every hit.

Please note that different dimensionalities of track representations and reconstruction hits willautomatically be handled correctly. Two examples shall illustrate this behavior:

1. One has a 1-D strip detector and a 4-D track model, which is used for tracking withoutmagnetic fields (define xk = (u,v,du/dw,dv/dw)T for a straight line where ~u and ~v spanthe detector plane, and ~w = ~u×~v points along the momentum vector. The orientation of~u is chosen such that the detector measures the u coordinate). The Hk matrix is defined asHk = (1,0,0,0), so that Hk · x̃k will correctly be one-dimensional. The residual rk|k−1 is thenalso one-dimensional. The Kalman gain is a 4×1 matrix, and the χ2-increment is correctlycalculated for one degree of freedom, in the sense that rk|k and (Vk −HkCk|kHTk ) are scalars.

2. One has a 2-D pixel detector and a 5-D trajectory model for charged particle tracking inmagnetic fields. The detector measures the coordinates u and v in the detector plane, andthe state vector is xk = (q/|~p|,du/dw,dv,dw,u,v)T . The 2×5 Hk matrix is then:

Hk =

(0 0 0 1 00 0 0 0 1

)1This method is the only place, where track representations and reconstruction hits are explicitly synchronized.

Each hit class has to define here which track representations it supports.

7


All matrices and vectors automatically appear in the right dimensionality. mk and rk|k−1 are2-vectors, Vk is a 2×2 matrix, the Kalman gain is a 5×2 matrix, and χ2 is a scalar whichis calculated from two degrees of freedom (rk|k is a 2-vector, and (Vk−HkCk|kHTk ) is a 2×2matrix.

1.3 Track Candidates

Track finding or pattern recognition is a task which precedes the fit of a track. External algorithmsmust determine a set of hits which belong to one track. This list of hits has to be sorted. Asmall amount of wrongly sorted hits is usually unavoidable, and does not hurt the fit. If hits werecompletely unsorted however, the fit should in principle still work, but the results should have aless than optimal accuracy, due to long extrapolations in between the hits and the related multiplescattering and energy loss straggling and increased numerical uncertainty.This sorted hit list is passed to GENFIT in form of an instance of the GFTrackCand class. Thisclass holds two lists of integer numbers (std::vector). One hit has an entry in bothlists, which contain the detector ID of the hit, and the index of the hit in its detector’s hit arrayrespectively. This information is used to create the reconstruction hits from the reconstructedclusters in the detectors for all hits belonging to the track. This is discussed in section 1.5.4, whichdescribes the GFRecoHitFactory class.

1.4 Track Representations

The track of a charged particle in a magnetic field can be parameterized in many different ways.Parameters can be “global” (e.g. distance of closest approach to the z-axis, or azimuthal locationof this point) or “local” (e.g. direction of the particle in a certain plane, or point of entry intoa certain volume). In GENFIT, both global and local parametrizations can be used. The trackrepresentation which is described as an example in section 1.4.1 is a local parametrization. Theonly hard requirement to all track parametrizations is that the transformation from the vector spaceof state vectors to the vector space of detector hits must be linear, i.e. there must exist a matrix Hkwhich provides for Hk · xk to be in the vector space of detector hits, i.e. the detector plane.

All track representations in GENFIT must inherit from the abstract base class GFAbsTrackRep.A C++ class is called abstract if it contains at least one method which is declared as virtual=02.It can not be instantiated. Derived classes must override all virtual=0 methods and can be in-stantiated. For all C++ technicalities, please refer to a text book on C++, e.g. [6]. This mech-anism of so-called polymorphism is used in GENFIT to decouple the algebra of the filter algo-rithm from the track extrapolation code. The following example of the GFKalman class’ call tothe extrapolate() method of a track representation called GeaneTrackRep via the base classpointer GFAbsTrackRep* rep shall illustrate this:

2e.g. virtual void f()=0;

8

Track Representations

ConcreteTrackRep

GFAbsTrackRep

inherits from

providesimplementation

state cov

extrapolateToPoint(Vector_t& ...)

extrapolate(GFDetPlane& ...)

contains

importantvirtual methods

GeaneTrackRep

Local Straight Linetrack representation

for dipole spectrometer

e.g.

external track extrapolationcode (e.g. GEANE)

intializes

Kalman filter

interacts withtrack representation

through

extrapolateToLine(Vector_t&, Vector_t&, ...)

implements

track extrapolationcode expert

Figure 1.3: Implementation of a concrete track representation through the abstract interfaceGFAbsTrackRep.

class GFAbsTrackRep{ 1

public: 2

virtual double extrapolate(const GFDetPlane& plane, 3

TMatrixT& statePred, 4

TMatrixT& covPred)=0; 5

... 6

}; 7

class GeaneTrackRep : public GFAbsTrackRep { 8

public: 9

double extrapolate(const GFDetPlane& plane, 10

TMatrixT& statePred, 11

TMatrixT& covPred); 12

... 13

}; 14

void GFKalman::processHit(GFAbsRecoHit* hit, GFAbsTrackRep* rep){ 15

... 16

rep->extrapolate(pl,state,cov); 17

... 18

} 19

If the concrete track representation, the pointer rep points to, is of the type GeaneTrackRep, then

9


GeaneTrackRep::extrapolate(...) will be called in the GFKalman::processHit(...)method (line 17). If it were of another concrete type ConcreteTrackRep2 then thisclass’ ConcreteTrackRep2::extrapolate(...) would be called. This way the Kalmanfilter does not need to have any knowledge on how the track extrapolation is actu-ally realized inside the concrete track representation. It just uses the interface methodGFAbsTrackRep::extrapolate(...) to access the concrete implementation of whichever con-crete type is behind GFAbsTrackRep* rep (via the so-called virtual table of the class).

Figure 1.3 gives a summarizing overview over the implementation of track representations. It alsolists the extrapolation methods which have to be provided by the concrete track representation.The method

virtual double extrapolate(const GFDetPlane& plane,

TMatrixT& statePred,

TMatrixT& covPred)=0;

must be overridden. It is however optional to override the methods

virtual void extrapolateToPoint(const TVector3& point,

TVector3& poca,

TVector3& normVec);

virtual void extrapolateToLine(const TVector3& point1,

const TVector3& point2,

TVector3& poca, TVector3& normVec,

TVector3& poca_onwire);

for which a standard implementation exists in GFAbsTrackRep.cxx, which will terminatethe program with an error message. This means that if the extrapolateToPoint(...) orextrapolateToLine(...) are called for track representations in which these methods are notoverridden, the program will abort. Such a situation is to be avoided by the user.The latter two methods are optional because they are usually only used for the calculation of virtualdetector planes (see section 1.5.1.1). They are not needed for a fit with just planar detectors.

1.4.1 GeaneTrackRep

A concrete track representation which has been implemented in PANDAroot is calledGeaneTrackRep. It utilizes the FORTRAN code GEANE [7] which is nowadays distributed aspart of CERN’s Virtual Monte Carlo (VMC) package [8]. The interface code to the PANDA-root framework has been developed by M. Al-Turany (GSI Darmstadt, Germany), A. Fontana, L.Lavezzi, and A. Rotondi (all INFN Pavia, Italy). I want thank them for this effort and for the fruit-ful collaboration in debugging the code. After some bug fixing, GEANE is a stable and reliabletrack extrapolation tool, and its combined use with GENFIT successfully solves the problem ofcharged particle track fitting in PANDAroot. It is especially useful, since it can carry out all threegenerally required extrapolations in GENFIT: 1) extrapolate to a plane; 2) extrapolate to the point

10

Reconstruction Hits

of closest approach to a point; 3) extrapolate to the point of closest approach to a line (a wire).State vectors for this track representation are defined as xk = (q/|~p|,du/dw,dv/dw,u,v)T , wherethe detector plane is spanned by the vectors ~u and ~v and ~w = ~u×~v points along the momentumvector ~p. q denotes the particle’s charge.

1.5 Reconstruction Hits

Figure 1.4 illustrates the working principle of reconstruction hits in GENFIT. The Kalman filter

UserRecoHit

class template:GFRecoHitIfc

GFAbsRecoHit

inherits from

inherits from

providesimplementation

coord cov

getDetPlane(GFAbsTrackRep* ...) (abstract)

getHMatrix(GFAbsTrackRep*) (abstract)

contains

importantvirtual methods

GFPlanarHitPolicy

GFSpacepointHitPolicy

policy classspecialization e.g.

physical DetPlane

contains

virtual DetPlane

calculates

constructorUserRecoHit(RecoCluster*)

intializes

Kalman filter

interacts withhits through

residualVector(GFAbsTrackRep* ...)

implements

implements

detector codedeveloper

Figure 1.4: Structure of reconstruction hits in GENFIT.

interacts with the hits via the abstract interface class GFAbsRecoHit. But the user-implementedUserRecoHits do not inherit directly from GFAbsRecoHit. They inherit from the class templateGFRecoHitIfc, which is itself derived from GFAbsRecoHit. This intermediatelevel of inheritance, though adding complexity and an additional level of indirection, has manyadvantages. It allows simple UserRecoHit implementations, avoidance of code duplication inreconstruction hits, and for a software design which reflects well the classification scheme ofdetectors which was given at the beginning of this chapter, e.g. into planar, space-point, and wiredetectors (see the right hand side of figure 1.4). This scheme is however slightly complicated, soit is explained thoroughly in this section. After a description of the general inheritance structure(which class overrides which method), the discussion of two examples should make the use and theusefulness of the concepts clear. The full chain of inheritance reads as following (some methodsand all data members are omitted):

11


class GFAbsRecoHit { 1

virtual TMatrixT getHitCov(const GFDetPlane&)=0; 2

virtual TMatrixT getHitCoord(const GFDetPlane&)=0; 3

virtual const GFDetPlane& getDetPlane(GFAbsTrackRep*)=0; 4

virtual void getHMatrix(const GFAbsTrackRep* stateVector)=0; 5

virtual TMatrixT residualVector(const GFAbsTrackRep* stateVector, 6

const TMatrixT& state, 7

const GFDetPlane& d) { 8

TMatrixT H = getHMatrix(stateVector); 9

return ( getHitCoord(d) - (H*state )); 10

} 11

}; 12

//---------------------------------------------------------------------- 13

template 14

class GFRecoHitIfc : public GFAbsRecoHit{ 15

HitPolicy fPolicy; 16

virtual const GFDetPlane& getDetPlane(GFAbsTrackRep* rep) 17

{return fPolicy.detPlane(this,rep);}//from HitPolicy 18

virtual TMatrixT getHitCoord(const GFDetPlane& plane) 19

{return fPolicy.hitCoord(this,plane);}//from HitPolicy 20

virtual TMatrixT getHitCov(const GFDetPlane& plane) 21

{return fPolicy.hitCov(this,plane);}//from HitPolicy 22

}; 23

//---------------------------------------------------------------------- 24

class GFSpacepointHitPolicy { 25

const GFDetPlane& detPlane(GFAbsRecoHit*, GFAbsTrackRep*); 26

TMatrixT hitCoord(GFAbsRecoHit*,const GFDetPlane&); 27

TMatrixT hitCov(GFAbsRecoHit*,const GFDetPlane&); 28

}; 29

//---------------------------------------------------------------------- 30

typedef GFRecoHitIfc SpacepointRecoHit; 31

class UserRecoHit : public SpacepointRecoHit { 32

UserRecoHit(const TVector3&,const TVector3&); 33

virtual void getHMatrix(const GFAbsTrackRep* stateVector); 34

}; 35

All classes which are to be used as HitPolicy must implement the three methods detPlane(),hitCoord(), and hitCov() with the correct return values and argument lists. An example isgiven here with the class GFSpacepointHitPolicy. The only purely virtual method which re-mains to be overridden by UserRecoHit is getHMatrix().

12

Reconstruction Hits

1.5.1 Example 1: A TPC Reconstruction Hit

A Time Projection Chamber measures space points along the particle trajectory. These hits areclearly not defined in any kind of physical detector planes. The principle of detector planes ishowever still applied to them, using the concept of so-called virtual detector planes (1.5.1.1).Two classes are to be written for the TPC reconstruction hits: GFSpacepointHitPolicy andTpcRecoHit. The policy class is reusable for every other space point detector.

1.5.1.1 Virtual Detector Planes

A χ2-minimization of a track to space point hits is achieved when the sum of squared orthogonaldistances (normalized to the errors) is minimal. For this reason the detector plane for a space pointhit must contain the hit point and the point of closest approach of the track to the hit point. Thenthe residual vector is orthogonal to the track and the Kalman filter can minimize the orthogonaldistance. The natural, most general choice for the plane is the orthogonal to the track in the pointof closest approach. This is illustrated in figure 1.5. This means however that the orientation ofthe plane will depend on the track parameters, which can even be different for the same physicaltrack through detector, but for fits with different seed values. The extrapolated track from the lasthit could point to another place or direction or could have another curvature. The consequenceis that the detector plane of the reconstruction hit must be calculated each time this hit is to beused in a Kalman step. These kinds of dynamically calculated detector planes are named virtualdetector planes. The class which determines the orientation of the planes for space point hits iscalled GFSpacepointHitPolicy.Virtual detector planes are also very important for wire-based drift chambers in non-planar geome-tries. For these detectors the plane is situated in the point of closest approach of the track to thewire, and is oriented to contain the whole wire. The spanning vectors are chosen to lie perpendicu-lar (~u) and along (~v) the wire. The wire position and drift time are then measurements of u, and thev coordinate could be measured via double-sided readout with charge sharing or time correlation.The class which realizes these virtual detector planes is called GFWirepointHitPolicy.

1.5.1.2 GFSpacepointHitPolicy

Every hit policy has to implement the methods detPlane(), hitCoord(), and hitCov() withthe correct prototypes as called in GFRecoHitIfc. The compiler ensures that allneeded methods are defined correctly. This virtue of the template mechanism motivated its use inGENFIT.

The GFSpacepointHitPolicy::detPlane(GFAbsRecoHit*, GFAbsTrackRep*) methoduses the GFAbsTrackRep::extrapolateToPoint() method to find the point of closestapproach of the track to the hit position. The origin vector of the plane ~o is set to the hitposition. The span vector ~u is chosen dynamically, depending on the orientation of the plane’snormal vector ~n (which points in parallel with the momentum vector). This happens in theGFDetPlane::setNormal() method which is called from the detPlane() method. If the x

13


component of~n (with |~n |= 1) is greater than 0.1, then

~u =1√

(−ny−nznx )2 +2

−ny−nz

nx11

If the x component of ~n is very small, this choice becomes unfavorable. If the y component is

Figure 1.5: Virtual detector plane for a space point hit. The particle track is drawn in black, thered sphere represents the hit, the blue line indicates the residual vector, and the two arrows arethe span vectors of the virtual detector plane (gray).

14

Reconstruction Hits

greater than 0.1, the choice is:

~u =1√

(−nx−nzny )2 +2

1−nx−nzny1

And if only the z component is reasonably sized (~n is almost parallel to the z-axis):

~u =1√

(−nx−nynz )2 +2

11−nx−ny

nz

All three choices fulfill~n ·~u = 0. The other span vector is~v =~n×~u.

The method GFSpacepointHitPolicy::hitCoord() converts the coordinates of the hit pointinto the plane coordinates (u,v). Since the origin of the plane was chosen to coincide with the hitposition, these coordinates are (0,0). Anyway, the conversion into the plane coordinates is donein this method, for the case that the choice of the plane origin would change.With the plane origin ~o and the raw hit position ~Praw the coordinates are:

u = (~Praw−~o) ·~uv = (~Praw−~o) ·~v

The last method GFSpacepointHitPolicy::hitCov() converts the raw hit covariance matrixVk,raw, into a covariance matrix for the uncertainty and the correlation in the measurement of the(u,v) coordinates, Vk:

J =

ux vxuy vyuz vz

Vk = JT ·Vk,raw · J

It is obvious that the covariance matrix Vk contains a non-zero correlation parameter of the errorsin u and v which are themselves a mixture of the x-, y-, and z-resolutions. This is absolutelynecessary for the correct treatment of space point hits.

1.5.1.3 TpcRecoHit

All that is left to do in the class TpcRecoHit is to override the purely abstractmethod GFAbsRecoHit::getHMatrix(), and to fill the raw hit coordinates ~Praw and rawhit covariance matrix Vk,raw. These are saved in TMatrixT hitCoord andTMatrixT hitCov which are members of GFAbsRecoHit. This is done in the con-structor of TpcRecoHit. There is a special convention for the prototypes of reconstruction hitconstructors in GENFIT, which is needed to use the class GFRecoHitFactory which is detailed insection 1.5.4. If the TcpRecoHit is to be created from a reconstructed cluster, called TpcCluster,the constructor needed for the factory is TpcRecoHit(TpcCluster*). The class declaration is:

15


typedef GFRecoHitIfc SpacepointRecoHit; 1

class TpcRecoHit : public SpacepointRecoHit { 2

TpcRecoHit(TpcCluster*); 3

virtual void getHMatrix(const GFAbsTrackRep* stateVector); 4

}; 5

An example implementation of the getHMatrix() method for the use of TpcRecoHits with theGeaneTrackRep of section 1.4.1 is:

void TpcRecoHit::getHMatrix(const GFAbsTrackRep* stateVector) { 1

if (dynamic_cast(stateVector) != NULL) { 2

TMatrixT H(2,5); 3

H[0][0] = 0.; H[0][1] = 0.; 4

H[0][2] = 0.; H[0][3] = 1.; 5

H[0][4] = 0.; 6

H[1][0] = 0.; H[1][1] = 0.; 7

H[1][2] = 0.; H[1][3] = 0.; 8

H[1][4] = 1.; 9

return H; 10

} 11

else { 12

std::cerr

Reconstruction Hits

GFKalman

const GFDetPlane& GFRecoHitIfc::

getDetPlane(GFAbsTrackRep* rep)

space point hit (TpcRecoHit)const GFDetPlane&

GFAbsRecoHit::getDetPlane(GFAbsTrackRep* rep)

calls

call overvtable

const GFDetPlane&GFSpacepointHitPolicy::detPlane(GFAbsRecoHit*,

GFAbsTrackRep*)with arguments (*this,rep)

calls

GFAbsTrackRep::extrapolateToPoint(const TVector3& point, TVector3& poca, TVector3& normVector)

with point = hit position

GFDetPlanewith origin vector o = hit position,

and normal vector n = direction in poca

calls

providespoint of closest approach

and direction in poca

returns creates

Figure 1.6: Call to GFAbsRecoHit::getDetPlane() for TpcRecoHit.

GFKalman

const GFDetPlane& GFRecoHitIfc::getDetPlane(GFAbsTrackRep* rep)

planar detector hit (SilPixRecoHit)const GFDetPlane&

GFAbsRecoHit::getDetPlane(GFAbsTrackRep* rep)

calls

call overvtable

const GFDetPlane&GFPlanarHitPolicy::detPlane(GFAbsRecoHit*,

GFAbsTrackRep*)with arguments (*this,rep)

calls

physical detector plane

returns GFPlanarHitPolicycontains

Figure 1.7: Call to GFAbsRecoHit::getDetPlane() for SilPixRecoHit.

17


1.5.4 RecoHitFactory

The reconstruction hits are constructed from the measured clusters in the detectors. This is inprinciple a duplication of information, since both objects contain the hit position and covariance.But the reconstruction hits offer a lot of functionality which is needed for their use in the track fit.In the PANDAroot framework the detector clusters are persistent objects. So, currently GENFIThandles the reconstruction hits as transient objects. They are created before the fit, but they are notpersisted together with the GFTracks, and their GFTrackCand and GFAbsTrackReps.

The convenient mechanism for the simple creation of reconstruction hits in GENFIT iscalled GFRecoHitFactory. An instance of this class holds an associative array ofGFAbsRecoHitProducer* with an integer key (std::map).The integer key denotes the detector ID of a hit.

The following code listing shall demonstrate what a hit producer does. It is the content ofGFRecoHitProducer.h (where lines of code have been omitted, especially all the safety checks):

class GFAbsRecoHitProducer { 1

virtual GFAbsRecoHit* produce(int index)=0; 2

virtual ~GFAbsRecoHitProducer(); 3

}; 4

5

template 6

class GFRecoHitProducer : public GFAbsRecoHitProducer { 7

TClonesArray* hitArrayTClones; 8

GFRecoHitProducer(TClonesArray*); 9

virtual GFAbsRecoHit* produce(int index); 10

}; 11

12

template 13

GFAbsRecoHit* GFRecoHitProducer::produce(int index) { 14

return ( new recoHit_T( (hit_T*) hitArrayTClones->At(index) ) ); 15

} 16

In short, a call to GFAbsRecoHitProducer::produce(int index) for a hit producer ofa certain kind, e.g. GFRecoHitProducer, will call the con-structor TpcRecoHit(TpcCluster*) for the element index in the hit array. The hit is aTClonesArray*3, which is used in PANDAroot to hold the clusters.

The job of GFRecoHitFactory is to create a std::vector with all the cor-rect reconstruction hits in a GFTrackCand. This works as follows:

//initialization

GFRecoHitFactory *factory = new GFRecoHitFactory();

3see http://root.cern.ch/root/html522/TClonesArray.html

18

Reconstruction Hits

// detId ClusterClass,RecoHitClass hitArray

factory->addProducer(1,new GFRecoHitProducer(hitarray1));



//create the hits

std::vector recoHits = factory->createMany(trackcand);

The instance of GFTrackCand holds two lists of indices. Each hit is has a detector ID, andan index in the hit array. In the createMany() method, the factory will make the correctRecoHitX(ClusterX*) constructor call for every hit in the track candidate. The template mech-anism of C++ makes sure, at compile time, that all the required constructors exist.

19


1.6 Using GENFIT - Just a few Lines

The structure of GENFIT is slightly complex. Its use on the other hand is quite simple. Thefollowing example discusses a fit for hits in a TPC (which has detector ID 3). It includes theinitialization of the hit loading mechanism, and hit loading itself.In the initialization of the fitting job, one would do:

factory = new GFRecoHitFactory();

factory->

addProducer(3,new GFRecoHitProducer(hitarray));

The framework code has to take care that before each event, the hitarray is loaded with theclusters belonging to the event. Then, after pattern recognition has determined which hits belongto which track and filled this information into instances of GFTrackCand, in a loop over thosetrack candidates one does:

GFTrack* track = new GFTrack(new GeaneTrackRep(/*starting values for track

rep from pattern reco*/) );

track->setCandidate(trackcand);

track->addHitVector(factory->createMany(trackcand));

The track fit is performed with

GFKalman fitter;

fitter.processTrack(track);

The track now contains the fitted track parameters.

1.7 Persistency of Objects

GENFIT uses the mechanisms of ROOT to enable the user to save the results of the fit to files.That is why all data classes in GENFIT are derived from ROOT’s TObject class. The so-calleddictionary which is created by the program rootcint implements a Streamer() method for allthe classes to serialize and deserialize objects4. ROOT is in principle capable to persist all C++STL containers, but nevertheless comes with own container classes, which have certain advan-tages. The track representations in the GFTrack class are stored in a TObjArray. The use ofa TClonesArray is out of question, because it can not store objects of different classes (pleaseremember that track representations in the same track are accessed via the common interface classGFAbsTrackRep, but can in fact be very different from each other).The persistency mechanism for GENFIT’s GFTrack objects and all its content is well tested andworks stably.

4See chapter 15 of the ROOT User’s Guide at ftp://root.cern.ch/root/doc/15AddingaClass.pdf for more details.

20

Statistical Tests and Results

1.8 Statistical Tests and Results

GENFIT has by now been used for detailed studies of different tracking detectors in PANDAroot.These realistic detector studies are however not suitable to quantitatively test the performance ofGENFIT. The unknown resolutions of the detectors with their realistic digitizations enter, andthe track extrapolation needs to correctly take the effect of the materials in between the hits intoaccount. Although it has been shown that GEANE does this correctly, a simplified benchmarkgeometry was chosen. The particles cross a vacuum (to decouple the material effects) in a con-stant magnetic field. Track following and fitting in this test are done with GeaneTrackRep. Theprogram samples points on the trajectory in distances of 1cm. These points are smeared withGaussian distributions of known widths. Like in a TPC, the x- and y-measurements are assumedto have equal and better resolutions than the z-coordinate measurements. These smeared pointsare used in the fit as reconstruction hits based on GFSpacepointHitPolicy. Behind the last hit, areference plane is defined in which the fitted track parameters are compared to their true values toobtain residual and pull distributions5. This is illustrated in figure 1.8. If the fit is able to correctlydetermine the track parameters and their errors the pull distributions have to be Gaussians of widthσ = 1 and of mean value 0. Figure 1.10 shows the five pull distributions for the track parameters,which nicely fulfill these criteria. This is especially nice because the fit obviously takes the asym-metric errors of the hits into account correctly. The selected polar angle and momentum are justexamples. The fitter works fine also for other values of these variables.

Figure 1.8: Illustration of geometry of GENFIT benchmark application. The smeared hit posi-tions are indicated in blue, the seed value for the track parameters is illustrated in orange, andthe fit result is drawn in yellow. The gray reference plane is used to obtained the pull distribu-tions of figure 1.10. The track is extrapolated to this plane and the resulting track parametersare compared to their true values.

5The distribution of (xfit− xtrue)/σx

21


2χ0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2 2.2 2.40

20

40

60

80

100

120

140

160

12 planes strip detectors & 13 space point

Figure 1.9: Reduced χ2-distribution for a fitting benchmark. The fit was carried out with twelveplanes of strip detectors and 13 space points. The black line is the analytical reduced χ2-distribution for 33 degrees of freedom (see text) where only the normalization is fitted.

Another test was taken out with a slightly different geometry. Twelve hits in crossed planar stripdetectors were fitted together with 13 space point hits. The reduced χ2-distribution of the fittedtracks is expected to be described by the analytical χ2 distribution for 33 degrees of freedom. Thestrip hits each contribute one degree of freedom, the space point hits each contribute two degreesof freedom (they only constrain the track in a plane perpendicular to the track), and the trackparameters subtract five degrees of freedom (12 + 2 ·13−5 = 33). The simulation result and theanalytical distribution can be seen in figure 1.9. Only the normalization of this distribution wasfitted. It describes the simulation result very well.

An example of a detector study which was done with GENFIT is the determination of the mo-mentum resolution of the PANDA TPC. It is shown in figure 1.11 [9]. This detector surrounds theinteraction point of the PANDA experiment, and is situated in a 2T solenoid field. It has an ac-ceptance for tracks emitted between 20◦ and 130◦ with respect to the beam axis. The shorter pathlength through the detector for polar angles around 90◦ is responsible for the worse momentumresolution in this region. The resolution becomes much worse close to the edges of the acceptance,where the path length through the detector goes to zero.Many hundreds of thousands of tracks were fitted reliably for this study, and the smooth structuresin the plot indicate a correct description of the systematics by the fit.

22

Statistical Tests and Results

pull of momentum

-10 -8 -6 -4 -2 0 2 4 6 8 100

100

200

300

400

500

600

mean = 0.010

= 0.996σ

° = 25θ1 GeV/c muons under

pull of coordinate u

-10 -8 -6 -4 -2 0 2 4 6 8 100

100

200

300

400

500

600

mean = -0.012

= 1.008σ


pull of coordinate v

-10 -8 -6 -4 -2 0 2 4 6 8 100

100

200

300

400

500

600

mean = -0.022

= 0.992σ


pull of slope u'

-10 -8 -6 -4 -2 0 2 4 6 8 100

100

200

300

400

500

600

mean = 0.011

= 0.996σ


pull of slope v'

-10 -8 -6 -4 -2 0 2 4 6 8 100

100

200

300

400

500

600

mean = 0.010

= 0.999σ


Figure 1.10: Pull distributions for the five track parameters of GeaneTrackRep obtained likeillustrated in figure 1.8.

23


angle w.r.t. beam axis [deg]20 40 60 80 100 120 140 160

/ p

pσ

0

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.10.2 GeV/c

0.4 GeV/c

0.6 GeV/c

0.8 GeV/c

1.0 GeV/c

1.2 GeV/c

1.5 GeV/c

Figure 1.11: Momentum resolution of the PANDA TPC as a function of the track angle withrespect to the beam axis. The different curves represent different track momenta, as indicatedin the legend. [9]

1.9 Summary and Outlook

GENFIT is a software package which organizes track fitting in particle spectrometers in a novelway. The fitting algorithms operate on track representations and reconstruction hits. Through apolymorphic implementation, the algorithms do not need to know about the specific nature andstructure of the hits and track representations. Even the dimensionality of the reconstruction hitsand track representations are transparent, but are automatically taken into account correctly. GEN-FIT allows the user to define unordinary kinds of hit geometries, like the space point hits or wirehits or even four dimensional hits which define the measurement of a point together with a direc-tion.

GENFIT is used in the PANDAroot framework together with a track representation which is basedon the track extrapolation code GEANE. It is used for detector studies and global tracking andworks stably. Benchmark studies have shown that GENFIT calculates track parameters and co-variance matrices correctly, and that it delivers correct χ2-distributions.Due to its flexible design, the application of GENFIT to other experiments in high energy physicsis straightforward. But its use is not limited to track fitting with a Kalman filter. We plan to investi-gate other iterative track fitting algorithms, like the Gaussian Sum Filter or even to apply GENFITto the task of vertex fitting.

24

Summary and Outlook

Acknowledgments

Most of all I would like to thank Sebastian Neubert (TU München) for developing GENFIT withme. It was a lot of fun, and I learned a lot about object oriented programming in the process.I also want to thank Felix Böhmer (TU München) for his valuable help in applying GENFIT todata and for his help in debugging this complex piece of code. My thanks also go to my supervisorsBernhard Ketzer and Stephan Paul for their support and for valuable discussions.Many thanks to Mohammad Al-Turany (GSI Darmstadt, Germany), Andrea Fontana, Lia Lavezzi,and Alberto Rotondi (all INFN Pavia, Italy) for developing the PANDAroot interface to GEANEwhich was essential for making GENFIT the working track fitting software for PANDA. Thanks alot to Lia for our good collaboration in debugging GEANE and GeaneTrackRep.

25

Appendix A

Mathematics of the Kalman Filter

The equations of the Kalman filter in the so-called gain formalism were already introduced insection 1.1. Many text book and articles on the topic discuss these equations, but they usually lackan easy-to-follow, full derivation of them. Such a derivation is presented in this chapter. None ofthe following mathematics were of course invented here, which is why they were moved to theappendix. For convenience table 1.1 is repeated here without the χ2-relevant items:

mk = Hkx̃k + vk Hit coordinates vector (can be one-dimensional). Hits arecounted with the index k.

x̃k The (unknown) true state vector.Hk Linear transformation from the vector space of state vec-

tors to the vector space of detector measurements. Thematrix has the dimension dim(mk)×dim(x̃k).

vk Deviation or noise of the position measurement.Vk = Cov(vk) Covariance of measurement noise vk.

xk|k−1 Predicted state vector at the detector plane of hit k. Itcontains all information of the hits up to index k−1 and isextrapolated from there.

Ck|k−1 = Cov(x̃k − xk|k−1) Predicted covariance matrix. It contains all informa-tion of the hits up to index k− 1 and is extrapolated fromthere, taking into account multiple scattering and energyloss straggling.

rk|k−1 = mk −Hkxk|k−1 Residual vector of the measurement and the extrapolatedtrack.

Rk = HkCk|k−1HTk +Vk Covariance of the residual, see derivation below.Kk = Ck|k−1HTk R

−1k Optimal Kalman gain, see derivation below.

xk|k = xk|k−1 +Kkrk|k−1 Updated state vector.Ck|k = (I−KkHk)Ck|k−1 Updated covariance matrix, with the identity matrix I.

See derivation below.

27

A MATHEMATICS OF THE KALMAN FILTER

A fit with the Kalman filter is successful, if the expectation value E(| x̃k−xk|k |2) is minimal, as theKalman filter is a Minimum Square Estimator. This expectation value can be expressed in termsof the covariance matrix Ck|k:

Ck|k = Cov(x̃k − xk|k) = E({x̃k − xk|k −E(x̃k − xk|k)}{x̃k − xk|k −E(x̃k − xk|k)}T )= E({x̃k − xk|k}{x̃k − xk|k}T )

Ck|k,i j = E({x̃k,i− xk|k,i}{x̃k, j − xk|k, j}) for the components

where the identity E(x̃k − xk|k) = 0 was used, which holds true if the model for x̃k is correct andthe starting values x0|0 are symmetrically distributed around the correct values for the track. Thefigure of merit for minization is then

E(| x̃k − xk|k |2) = E[N

∑i=1

(x̃k,i− xk|k,i)2] =N

∑i=1

E[(x̃k,i− xk|k,i)2] =N

∑i=1

(Ck|k,ii) = Tr(Ck|k)

The Kalman gain is introduced with the assumption that the filtered, updated state vector xk|k is:

xk|k = xk|k−1 +Kk · rk|k−1

with the Kalman gain matrix Kk. Then the covariance matrix is updated like:

Ck|k = Cov[x̃k − xk|k] = Cov[x̃k − (xk|k−1 +Kk · rk|k−1)]= Cov[x̃k − (xk|k−1 +Kk{mk −Hkxk|k−1})]= Cov[x̃k − (xk|k−1 +Kk{Hkx̃k + vk −Hkxk|k−1})]= Cov[(x̃k − xk|k−1)−KkHk(x̃k − xk|k−1)−Kkvk]= Cov[(I−KkHk)(x̃k − xk|k−1)−Kkvk]

In the next step, the following two rules for calculating vector covariances are used: 1) Cov(x1±x2) = Cov(x1)+Cov(x2) if x1 and x2 are uncorrelated. 2) Cov(Ax) = ACov(x)AT . And since vk iscompletely uncorrelated, because it just a property of the detector:

Ck|k = Cov[(I−KkHk)(x̃k − xk|k−1)]+Cov[Kkvk]= (I−KkHk)Cov[x̃k − xk|k−1](I−KkHk)T +KkCov[vk]KTk= (I−KkHk)Ck|k−1(I−KkHk)T +KkVkKTk= (I−KkHk)Ck|k−1(I−HTk KTk )+KkVkKTk= (I−KkHk)Ck|k−1− (I−KkHk)Ck|k−1HTk KTk +KkVkKTk= Ck|k−1−KkHkCk|k−1−Ck|k−1HTk KTk +KkHkCk|k−1HTk KTk +KkVkKTk= Ck|k−1−KkHkCk|k−1−Ck|k−1HTk KTk +Kk(HkCk|k−1HTk +Vk)KTk= Ck|k−1−KkHkCk|k−1−Ck|k−1HTk KTk +KkRkKTk

with the residual covariance Rk = Cov[rk|k−1] = HkCk|k−1HTk +Vk. This identity is easy to show:

Cov[rk|k−1] = Cov[mk −Hkxk|k−1] = Cov[Hkx̃k + vk −Hkxk|k−1] = Cov[Hk(x̃k − xk|k−1)+ vk] == HkCov[x̃k − xk|k−1]HTk +Cov[vk] = HkCk|k−1HTk +Vk = Rk

28

Bibliography

[1] The PANDA Collaboration. Technical Progress Report. Technical report, Facility for An-tiproton and Ion Research, Damstadt, Germany, Feb. 2005. cited in 1 (p. 2)

[2] S. Spataro. Simulation and event reconstruction inside the PandaRoot framework. Journalof Physics Conference Series 1193 (2008) 032035–+. cited in 1 (p. 2)

[3] R. E. Kalman. A New Approach to Linear Filtering and Prediction Problems. Transactionsof the ASME–Journal of Basic Engineering, Series D 82 (1960) 35–45. cited in 1.1 (p. 3)

[4] R. Frühwirth. Application of Kalman filtering to track and vertex fitting. Nuclear Instrumentsand Methods in Physics Research A 262 (1987) 444–450. cited in 1.1 (p. 3)

[5] R. Brun and F. Rademakers. ROOT - An object oriented data analysis framework. NuclearInstruments and Methods in Physics Research A 389 (1997) 81–86. cited in 1.2 (p. 5)

[6] B. Eckel. Thinking in C++, 2nd ed. Volume 1. Prentice Hall Inc. (www.bruceeckel.com),2000. cited in 1.4 (p. 8)

[7] M. Innocente, V. Mairie and E. Nagy. GEANE: Average Tracking and Error PropagationPackage. CERN Program Library, W5013-E (1991) . cited in 1.4.1 (p. 10)

[8] I. Hrivnacova, D. Adamova, V. Berejnoi, R. Brun, F. Carminati, A. Fasso, E. Futo, A. Gheata,I. Gonzalez Caballero, A. Morsch, and for the ALICE Collaboration. The Virtual MonteCarlo. ArXiv Computer Science e-prints . arXiv:cs/0306005. cited in 1.4.1 (p. 10)

[9] F. Böhmer. TU München. Diploma thesis in preparation (2009). cited in 1.8 (p. 22),1.11 (p. 24)

[10] K. B. Petersen and M. S. Pedersen. The Matrix Cookbook (matrixcookbook.com), Oct 2008.Version 20081114. cited in A (p. 29)

31

Title1 GENFIT - a Generic Toolkit for Track Reconstruction1.1 Kalman Filter1.2 The Structure of GENFIT1.3 Track Candidates1.4 Track Representations1.5 Reconstruction Hits1.6 Using GENFIT - Just a few Lines1.7 Persistency of Objects1.8 Statistical Tests and Results1.9 Summary and Outlook

A Mathematics of the Kalman FilterBibliography

genfitgenfit.sourceforge.net/genfit_v1_2.pdf · 1genfit - a generic toolkit for track...

Documents