\documentclass{CHEP2006}
\setlength{\paperheight}{297mm}
\setlength{\paperwidth}{210mm}
%%
%% Use \documentclass[boxit]{JAC2003}
%% to draw a frame with the correct margins on the output.
%%
%% Use \documentclass[acus]{JAC2003}
%% for US letter paper layout
%%
\usepackage{graphicx}
%%
%% VARIABLE HEIGHT FOR THE TITLE BOX (default 35mm)
%%
\setlength{\titleblockheight}{35mm}
%% DEFINITIONS
\def\hv{\vec{{\bf h}}}
\def\vv{\vec{{\bf v}}}
\def\mv{\vec{{\bf m}}}
\def\CM{{\bf C}}
\def\HM{{\bf H}}
%% DOCUMENT
\begin{document}
\title{RecPack, a general reconstruction toolkit}
\author{A. Cervera-Villanueva\thanks{Universit\'{e} the Gen\`{e}ve, CH},
J.J. G\'{o}mez-Cadenas\thanks{Universitat de Valencia, Spain},
J.A. Hernando\thanks{CERN, Geneva, CH, and Universidade de Santiago de Compostela, Spain}}
\maketitle
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{abstract}
%\abstract {
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
A general solution for the problem
%of reconstructing trajectories and vertices
of reconstructing
%(modeling)
the evolution of a dynamic system from a set of experimental measurements
is presented. This solution has been realised in a C++ toolkit that can incorporate
different methods for fitting, propagation, pattern recognition and simulation.
The RecPack functionality is independent of the experimental setup, what allows to apply
this toolkit to any dynamic system.
\end{abstract}
%\begin{keywords}
%reconstruction, kalman, track fitting.
%\end{keywords}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In high energy physics (HEP), as in other fields, one frequently faces the problem of
reconstructing the evolution of a dynamic system from a set of experimental measurements.
Most of reconstruction programs use similar methods. However, in general they are reimplemented for each
specific experimental setup. Some examples are fitting algorithms
(i.e. Kalman Filter~\cite{kalman1}-\cite{kalman2}),
equations for propagation, random noise estimation (i.e. multiple scattering), model corrections
(i.e. energy loss, inhomogeneous magnetic field, etc.), model conversion, etc.
%Notice that these equations are in general quite difficult to debug.
Similarly, the data structure (measurements, tracks, vertices, etc.), which can be
generalised as well, is not reused in most of the cases.
RecPack tries to avoid that by providing a setup--independent data structure and algorithms,
which can be applied to any dynamic system. The package follows an ``interface'' strategy, that is,
all the classes that could have a different implementation have their own interface,
in such a way that the rest of the classes do not depend on such a specific implementation.
This modular structure allows a great flexibility and generality.
%This paper is structured as follows. The architectural design of the package is presented in
%section \ref{sec:arch}. The geometry definition in section \ref{sec:geom}. In section
%\ref{sec:model} the model related methods are described.
%Sections \ref{sec:fit}, \ref{sec:nav}, \ref{sec:match}
%and \ref{sec:simul} are devoted respectively to the fitting, navigation, matching and simulation
%capabilities of the package.
%Finally the RecPack versions and clients are presented in section \ref{sec:clients}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Structure of the package}
\label{sec:arch}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
RecPack distinguishes between data classes (passive) and tools (active).
The tree of data classes is shown in Fig.~\ref{fig:arch_data}.
{\it EVector} and {\it EMatrix} are just a typedef of CLHEP's {\it HepVector} and {\it HepMatrix}
respectively (these are vectors and matrices of {\it double}'s with variable dimension).
This establish the only RecPack external dependence.
However, the user can replace the CLHEP classes by its favorite vector and matrix classes.
A structure that appears in several levels of the data model is the pair formed by
a vector of parameters ({\it EVector}) and its covariance matrix ({\it EMatrix}).
Thus, a new class called {\it HyperVector} has being introduced to hold this repeated structure.
For example, experimental measurements ({\it Measurement}) can be always reduced to a {\it HyperVector},
and the same is true for the fitting or propagation parameters ({\it State}).
%
%
\begin{figure}[htbp]
\centering
\includegraphics*[width=50mm]{arch_data.eps}
\caption{\label{fig:arch_data}
Architectural design of the data classes.}
\end{figure}
%
%
Before the track fitting occurs, a {\it Trajectory} is essentially defined as a collection of uncorrelated
{\it Measurement}'s. Track fitting results are stored in {\it State}'s. In the most general case,
the fitting parameters are local and therefore each {\it Measurement} must have a {\it State}
associated to it. An intermediate object, called {\it Node}, has being introduced to accommodate
the {\it Measurement}, the {\it State} and the quantities that relate both objects
(the residual {\it HyperVector}, the residual
{\it Surface}~\cite{foot2} and the local $\chi^2$ of the fit.). Consequently,
a {\it Trajectory} can be seen as a collection of {\it Node}'s, plus a set of global quantities as
the total $\chi^2$ of the fit, the number of degrees of freedom, etc.
Finally, two or more trajectories are connected by a {\it Singularity} (vertex, kink, decay), which
describes their discontinuities.
The classes {\it Surface}, {\it Volume} and {\it Setup} are treated in Sec. GEOMETRY.
%\ref{sec:geom}.
\begin{figure}[htbp]
\centering
\includegraphics*[width=80mm]{arch.eps}
\caption{\label{fig:arch}
Architectural design of the active classes (tools). $<$...$>$ means associative container. }
\end{figure}
The tools (see Fig.~\ref{fig:arch}) manipulate the data.
Most of them are pure interfaces (hence the I), allowing them to have different implementations.
Some of the tools contain sub-tools ({\it ISimulator, Model, IPropagator}, etc.).
If a tool has several sub-tools of the same type (i.e. {\it Model} has several {\it IProjector}'s),
these are stored in associative containers ($<$...$>$ in the graph), which permits the access
by key.
Tools are stored in services (\_svc in Fig.~\ref{fig:arch}), which not only actuate
as containers for the tools, but also as managers.
Indeed, the user interacts with the ``RecPackManager'' via its services.
%which provide user friendly methods.
For example, fitting a trajectory ({\it track}) by the least
squares method to a straight line model would look like:
\vspace*{0.5cm}
\noindent
{\it
manager().fitting\_svc().fit(``Lsq'', ``straight\_line'', track);
}
\vspace*{0.5cm}
%\vspace*{0.5cm}
%{\it
% IModelRep\& helix\_ray = \\ manager().model\_svc().model(``helix'').representation(``ray'');
%}
%\vspace*{0.5cm}
\noindent
In the following sections each of the services is treated individually.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Geometry}
\label{sec:geom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The RecPack geometry service provides the methods for the definition of the experimental setup
({\it Setup}), which is built through the addition of volumes ({\it Volume}) and
surfaces ({\it Surface}) with well defined position and axes inside the setup.
One can distinguish between base surfaces, which have no boundaries, and finite surfaces, which extend
the base class by incorporating a well defined size.
RecPack provides some predefined volume (box, tube --two concentric cylinders-- and sphere)
and surface types (plane: rectangle and ring; cylinder: cylinder and cylinder sector; sphere:
sphere and sphere sector), but adding new types is straight forward.
As an example, the following code defines a box called ``tracker'' placed inside the
``mother'' volume, and a surface called ``wall'' inside the tracker:
\vspace*{0.5cm}
\noindent
\begin{tabular}{ll}
{\it add\_volume(} & {\it ``mother'', ``tracker'', ``box'',} \\
& {\it pos, axis1, axis2, size );}
\end{tabular}
\noindent
\begin{tabular}{ll}
{\it add\_surface(} & {\it ``tracker'', ``wall'', ``rectangle'', } \\
& {\it pos, axis1, axis2, size );}
\end{tabular}
\vspace*{0.5cm}
\noindent
where pos, axis1, axis2 and size are {\it EVector}'s.
In this way, complicated setups as the one of Fig.~\ref{fig:harp} can be build.
\begin{figure}[htbp]
\centering
\includegraphics*[width=65mm]{harp_layout.eps}
\caption{\label{fig:harp}
Example of experimental setup corresponding to the HARP detector at CERN-PS~\cite{harp}.
}
\end{figure}
Geometrical objects may have properties, which are indirectly associated to them in the {\it Setup}
class. Typical volume properties are the ones that influence the evolution of the system
(magnetic field, radiation length, etc.). The following c++ code sets $x0$ (a {\it double})
as the radiation length of the ``tracker'':
\vspace*{0.5cm}
{\it set\_volume\_property( ``tracker'', ``X0'', x0 );}
%It is worth noting that some of the data classes are not completely passive,
%they are allowed to perform internal operations. For
%example {\it Volume}'s and {\it Surface}'s have the function {\it bool is\_inside(EVector$\&$)},
%which given a space point returns true if the point is inside the volume and false otherwise.
%An advanced feature of the geometry service is the possibility of
%having several worlds (see App. \ref{app:worlds}). For this reason
%volumes and surfaces do not belong directly to the Setup. Instead, an intermediate object
%called World has being introduced (see Fig. \ref{fig:arch_data}).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Model}
\label{sec:model}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The model service is the container and manager for model related equations:
intersection with surfaces, propagation and projection of states, random noise computation,
model conversion, etc. It contains an extensible collection of {\it Model}'s and the
corresponding transformations between them ({\it IModelConverter}'s). Each model
performs two major operations, propagation and projection:
%-------------------------
\subsection{Propagation}
%-------------------------
Propagation of states (which have a well defined position inside the setup) to a given
surface or final length is performed by the interface class {\it IPropagator}.
Intermediate calculations are delegated to smaller tools:
\begin{itemize}
\item $<${\it ISurfaceIntersector}$>$: it is a collection of {\it ISurfaceIntersector}'s,
each of which corresponds to a different base surface type (plane, cylinder, sphere).
Its job is to calculate the path length from the actual position to the given surface.
\item {\it IEquation}: it computes the state vector
% position and direction of the state
at a given length. This length
can be provided by an {\it ISurfaceIntersector}, in the case of propagation to a surface, and
externally by the user, in the case of propagation to a length.
\item $<${\it IModelCorrection}$>$: this kind of tool
applies a small correction to the propagation than by an {\it IEquation} (i.e. energy loss).
\item $<${\it INoiser}$>$: each of them computes the random noise covariance
matrix for the given length and for a specific type of noise
(i.e. multiple scattering, energy loss fluctuations).
\end{itemize}
%-------------------------
\subsection{Projection}
%-------------------------
\noindent
The projection operation transforms a state into a virtual measurement (predicted--measurement),
which can be
then compared with an experimental measurement to compute a residual. This is crucial for fitting and
matching algorithms. These virtual measurements may also be used by {\it ISimulator}'s
(see Sec. SIMULATION) to produced simulated measurements.
The state {\it HyperVector} is projected according to the following equations:
\begin{equation}
\mv^{pred} = \hv(\vv), \,\,\,\,\, \CM_m^{pred} = \HM \CM_v \HM^T \ ,
\label{eq:proj}
\end{equation}
\noindent
where $\hv$ is the projection function, which depends on the measurement type,
$\HM= \partial \hv / \partial \vv$ is the projection matrix,
$\mv^{pred}$ and $\vv$ are the predicted--measurement vector and
state vector respectively, and $\CM_m^{pred}$ and $\CM_v$ their corresponding
covariance matrices.
Several measurement types (``$xy$'', ``$uv$'', ``$xyz$'','' $r\phi$'', etc.)
may coexist in a single trajectory, which can be fitted to an unique model. To do so, each {\it Model}
must contain an extensible collection of {\it IProjector}'s, each of which corresponds
to a different measurement type.
%As we will see in forthcoming sections,
%this kind of projection is used by IFitter's (see Sec. \ref{sec:fit}) and matching functions
%(see Sec. \ref{sec:match}) to compute the residual HyperVector
%($\mv - \mv^{pred}$, $\CM_m + \CM_m^{pred}$), and also by ISimulator's (see Sec. \ref{sec:simul})
%to create ideal measurements from propagated states.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Fitting}
\label{sec:fit}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Fitting algorithms, called fitters, need two setup--dependent operations:
prediction of the next measurement based on the information provided by previous measurements
(propagation) and comparison between real and predicted measurements (projection)
to update the fitting parameters. Fitting equations can be kept independent of the model
and measurement type(s) if these two operations are external to the fitter. As described above,
propagation and projection are performed by each {\it Model}.
The fitting service is in charge of fitting clusters,
trajectories and vertices via its fitters ({\it IFitter}).
The user can either use one of the existing fitters or
provide his own. Two fitters for trajectories
(least squares and Kalman filter~\cite{kalman1}-\cite{kalman2})
and one for vertices (Kalman filter~\cite{kalman3}) are available.
%No {\it IClusterFitter} is implemented yet.
A trajectory fitter takes a raw {\it Trajectory} (a collection of {\it Node}'s with
{\it Measurement}'s and empty {\it State}'s) and
transforms it into a fitted {\it Trajectory}, in which the {\it State}'s have meaningful contents.
Similarly, the vertex fitter takes a raw {\it Vertex}
(in this case the measurements are the fitted trajectories while the state associated
to each trajectory is empty before the fit).
In the case of a Kalman Filter fit (for trajectories or vertices) a seed state must be provided.
The following example illustrates the functionality of this service:
a set of 2D measurements have been produced by a charged particle
in a magnetic field. These measurements have been already introduced in a raw {\it Trajectory}
({\it track})
and now we want to fit it, first by least squares, and then use the result of this fit
({\it track.state()}) as a seed for a Kalman filter fit. The necessary c++ code would be:
\vspace*{0.5cm}
{\it
fit(``Lsq'', ``Helix'', track);
fit(``Kalman'', ``Helix'', track, track.state());
}
\vspace*{0.5cm}
%In HEP the Kalman Filter fit \cite{kalman1}-\cite{kalman2} is frequently used for track
%and vertex fitting.
%It has the advantage of being local (the fitting parameters variate along the trajectory) and
%incremental (measurements are treated sequentially), what allows
%simultaneous pattern recognition and fitting, and detection of outliers. In addition, it solves the
%problem of inverting large covariance matrices. Indeed, the largest covariance matrix
%to be inverted has the dimensions of the state vector (5 for a Helix model). However,
%in a least squares fit, the dimension is $N\times N$, being N the number of measurements.
%Finally, random noise processes, as multiple scattering, can be easily incorporated through a single
%covariance matrix.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Navigation}
\label{sec:nav}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%The navigation service contains a collection of INavigator's, which perform
%the propagation of a given state to any surface, volume or length within
%the setup.
The main functionality of the navigation service is to propagate states to any surface,
volume or length within the setup. This operation is performed by special {\it IPropagator}'s, called
navigators, which are capable to handle the volume hierarchy and volumes with inhomogeneous properties.
One navigator (``RecPackNavigator'') is provided by default, but others can be added easily
(i.e. Geant4~\cite{geant4}).
The ``RecPackNavigator'' propagates the state in several steps.
Propagation in each step is performed by the {\it IPropagator}
associated to the {\it Model} in the actual volume.
Before and after each step a list of {\it IInspector}'s
(associated to volumes and surfaces) is called. An {\it IInspector} is a tool that performs
a concrete action: set the properties of the entering volume, sum up intermediate path lengths,
set the length of the next step (dynamic stepping), etc.
User defined {\it IInspector}'s can be added to any surface or volume.
For example, a ``CounterInspector'' could be added to a given surface in order to count the number of
times this surface is traversed.
Two important features of the ``RecPackNavigator'' are:
i) the intersection with surfaces~\cite{foot3} is done analytically whenever is possible
(and numerically otherwise) and ii) user defined {\it INavigationLogic}'s allow to establish
the sequence in which volumes and surfaces must be traversed.
%An special feature of the RecPackNavigator is that it can use
%an external {\it IPropagator} (i.e. Geant4) to perform the propagation of the state in each step.
%An INavigator extends the capabilities of an IPropagator, which propagates
%a State to a surface or length in a single step and within a single volume. Instead,
%the INavigator performs several steps to deal with several volumes and with volumes
%having inhomogeneous properties.
%The user can use one of the existing INavigator's or provide a new one.
%RecPack provides its own INavigator (``RecPackNavigator''). It distinguish between two types of
%propagation steps depending on the properties of the actual volume: to a surface and to a length.
%If any of the volume properties is inhomogeneous the propagation occurs through dynamic stepping
%\footnote{Several steps of variable length according to the derivative of the
%inhomogeneous property.}.
%If all the properties are homogeneous there is no reason for small steps.
%In that case ``RecPackNavigator'' propagates to the next intersected surface.
%Before and after each step a list of IInspector's (associated to volumes and surfaces) is called.
%An IInspector is a tool that performs a concrete action: set the properties
%of the entering volume, sum up intermediate path lengths, model conversion,
%set the length of the next step (dynamic stepping), etc.
%User defined IInspector's can be added to any surface or volume.
%For example, a CounterInspector could be added to a given surface in order to count the number of
%times this surface is traversed.
%The propagation inside a volume depends on the properties of the volume. For example,
%a charged particle inside a volume with non 0 magnetic field will be described by a helix.
%A volume can also have radiation length (for multiple scattering), density, etc. In general,
%any kind of property can be defined. The RecPackNavigator selects automatically the
%appropriate model equations for each volume according to its properties.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Matching}
\label{sec:match}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
This generic name refers to the methods that are related with pattern recognition (PR) problems.
In general, the purpose of PR algorithms is to distribute the existing
measurements into trajectories and these into vertices.
%This is a common problem in HEP, but it can be generalized to any other field.
On can distinguish two types of PR algorithms: matching functions, which serve to estimate
the probability of two objects of being
related to each other (trajectory--trajectory, measurement--trajectory, trajectory--vertex, etc.),
and PR logics, which define the
sequence in which such a relations are established. The first are always general, while
the second may have a strong setup dependence. PR logics are introduced
via three types of tools: {\it IClusterFinder}, {\it ITrajectoryFinder} and {\it IVertexFinder},
which build clusters ({\it Measurement}'s), trajectories and vertices respectively using the
available matching functions and following a specific strategy.
Currently, the RecPack matching service provides
trajectory--measurement, trajectory--trajectory and trajectory--vertex matching functions.
%\begin{enumerate}
%\item trajectory-measurement, trajectory-trajectory and trajectory-vertex matching functions.
%\item Measurement, trajectory and vertex selection functions.
% For example, the function
% {\it best\_matching\_measurement(...)}, computes the best matching measurement
% in a given volume or surface, for the specified trajectory.
%\end{enumerate}
For the moment, PR logics are not implemented. In the future, one could try to
identify common PR logics and include them in this service. For example, PR
in a series of parallel planes which produce 2D measurements occurs always in a similar way.
The same is true for a volume with 3D measurements (i.e. TPC), etc.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Simulation}
\label{sec:simul}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Some times reconstruction programs must operate over simulated measurements. However, in general
the user must provide the classes and methods that allow the interface between
simulation and reconstruction, which is not always an easy task.
The RecPack simulation service solves this problem by generating simulated measurements with the data
format required by the rest of the services.
%As usual, this service has an extendible collection of ISimulator's.
%RecPack provides its own ISimulator (``RecPackSimulator'').
The user must declare the active volumes and surfaces (the ones that produce measurements),
and specify the measurement type in each of them.
Active surfaces produce a measurement when they are intersected, while active volumes
produced measurements through dynamic stepping (see Sec. NAVIGATION)
%The ``RecPackSimulator'' uses the propagation equations of the
Given a simulation seed ({\it State}), the simulation service uses the navigation service
to produce an ideal trajectory inside the setup.
%the propagation equations of the
%model service via the INavigator, which for a given simulation seed
%defines the ideal trajectory inside the setup.
Then, a special {\it IInspector} (``MeasSimulator'') creates
ideal measurements (according to Eq.~\ref{eq:proj}) in the active volumes or surfaces by calling
the {\it IProjector} corresponding to the measurement type in that volume or surface.
Finally, propagation noise and experimental errors are introduced by a set of {\it INoiseGenerator}'s
(multiple scattering, energy loss fluctuations, measurement resolution, etc.).
This simple simulator does not attempt to be a full simulator (i.e. Geant4).
Instead, its main purpose is to serve as a debugging tool or as a fast simulator.
%For example,
%it is very useful to validate new IModel's,
%IFitter's, volume types, INoiser's, etc. It can be also used for analysis as a fast simulator.
Existing simulation toolkits, as Geant4, could be easily integrated into RecPack by implementing
%the {\it ISimulator} interface and
the {\it IInspector}'s that generate measurements in the different subdetectors. Such an inspectors
should be able to access the Geant4 information and then use it to create specific measurements.
%The measurements produced by an {\it ISimulator}
%are stored in a {\it std::vector}, which can be directly passed to the relevant RecPack
%services for pattern recognition, fitting, etc.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{RecPack versions and clients}
\label{sec:clients}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
RecPack was born in the HARP experiment at CERN-PS~\cite{harp} (see Fig.~\ref{fig:harp}).
The initial version, {\it RecPack-0} is being also used in MICE~\cite{mice}, MuScat~\cite{muscat}
and MIPP \cite{mipp}.
A reorganization of the code, {\it RecPack-1}~\cite{recpack-1}, was done in order to gain in
flexibility and generality. This version is being used by the SciBar detector, which
is part of the K2K experiment~\cite{k2k}, and served as inspiration for LHCb~\cite{lhcb}
reconstruction software and for
the design of future experiments as HERO and SuperNova~\cite{hero-supernova}.
The T2K~\cite{t2k} and NEMO~\cite{nemo}
Collaborations have recently shown interest in using RecPack as a toolkit for their reconstruction software.
A new version, RecPack-2, described in this article, is being realised at the moment
for these experiments. All other RecPack users will update to the new version as soon as it is ready.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusions}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In summary, RecPack is a modular and extensible reconstruction toolkit,
which provides the basic data structure and most of the common methods needed by any
reconstruction program: matching, fitting and navigation.
It also has functionality to perform a quick interface with simulation packages.
%The different RecPack services provide user friendly interface to control the
%the package functionality.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section*{Acknowledgments}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
We would like to thank Gersende Prior for her help with the Kalman Filter vertex fit.
The contribution of Malcolm Ellis and Federico Sanchez, as the main RecPack users,
has being essential for reporting a non negligible amount of bugs.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{thebibliography}{1}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\bibitem{IEEEhowto:kopka}
%H.~Kopka and P.~W. Daly, \emph{A Guide to {\LaTeX}}, 3rd~ed.\hskip 1em plus
% 0.5em minus 0.4em\relax Harlow, England: Addison-Wesley, 1999.
%\bibitem{foot1}
%The Kalman Filter fitting method is used
%in most of HEP experiments because its incremental strategy allows simultaneous pattern
%recognition and fitting, detection of outliers and an easy incorporation of random noise processes.
\bibitem{kalman1}
R.E. Kalman, J. Basic Eng. 82 (1960) 35 \\
R.E. Kalman, R.S. Bucy, J. Basic Eng. 83 (1961) 95
\bibitem{kalman2}
R. Fruhwirth, M. Regler, Nuc. Inst. Meth. A241 (1985) 115.
\bibitem{kalman3}
R. Fruhwirth. Nucl. Inst. Meth. A262 (1987) 444
\bibitem{foot2}
The residual is always calculated as the length of a geodesic over a surface.
\bibitem{geant4}
A. Dell'Acqua {\it et al.}, GEANT4 Collaboration,
Nucl. Inst. Meth. A506 (2003) 250.
\bibitem{foot3}
The problem of intersecting a volume is always reduced to the intersection with its outer walls.
\bibitem{harp} http://harp.web.cern.ch/harp/
\bibitem{mice} http://hep04.phys.iit.edu/cooldemo/
\bibitem{muscat} http://hepunx.rl.ac.uk/neutrino--factory/muons/muscat.html
\bibitem{mipp} http://ppd.fnal.gov/experiments/e907/e907.htm
\bibitem{recpack-1}
A. Cervera-Villanueva, J.J. Gomez-Cadenas and J.A. Hernando. Nucl. Inst. Meth. A534 (2004) 180-183
\bibitem{k2k}
S.H. Ahn. et {\it al}. The K2K Collaboration. Phys. Lett. B511 (2001) 178-184
\bibitem{lhcb} http://lhcb.web.cern.ch/lhcb/
\bibitem{hero-supernova}
No references available yet.
\bibitem{t2k} http://neutrino.kek.jp/jhfnu/
\bibitem{nemo}
R. Arnold et {\it al}. The NEMO Collaboration. Nucl. Inst. Meth. A536 (2005) 79-122
\end{thebibliography}
\end{document}