Content

• Reconstruction Framework
• Requirements and Guidelines
• AliReconstructor
• Local Reconstruction
• Vertexing
• Combined Track Reconstruction
• Filling of ESD
• Monitoring of Performance
• Classes
• Event Summary Data
• Run & Event Tag System
• Raw-data Reconstruction on CAF (updated)

Reconstruction Framework

This chapter focuses on the reconstruction framework from the (detector) software developers point of view.

Wherever it is not specified explicitly as different, we refer to the ‘global ALICE coordinate system’. It is a right-handed coordinate system with the z axis coinciding with the beam-pipe axis and going in the direction opposite to the muon arm, the y axis going up, and the origin of coordinates defined by the intersection point of the z axis and the central-membrane plane of TPC.

We also use the following terms:

• Digit: This is a digitized signal (ADC count) obtained by a sensitive pad of a detector at a certain time.
• Cluster: This is a set of adjacent (in space and/or in time) digits that were presumably generated by the same particle crossing the sensitive element of a detector.
• Reconstructed space point: This is the estimation of the position where a particle crossed the sensitive element of a detector (often, this is done by calculating the center of gravity of the ‘ cluster’).
• Reconstructed track: This is a set of five parameters (such as the curvature and the angles with respect to the coordinate axes) of the particle’s trajectory together with the corresponding covariance matrix estimated at a given point in space.

The input to the reconstruction framework are digits in root tree format or raw data format. First a local reconstruction of clusters is performed in each detector. Then vertexes and tracks are reconstructed and particles types are identified. The output of the reconstruction is the Event Summary Data (ESD). The AliReconstruction class provides a simple user interface to the reconstruction framework which is explained in the source code.

Requirements and Guidelines

The following list contains items that are considered important. The importance varies from essential to only nice-to-have and may depend on the personal point of view. The list and the importance of the items will change in time with the improved understanding of our needs:

• the prime goal is to provide the data that is needed for a physics analysis.
• it should be aimed for high efficiency, purity and resolution.
• the user should have an easy to use interface to extract the required information.
• the reconstruction code should be ef ficient but also maintainable.
• the reconstruction should be as fiexible as possible. It should be possible to do the reconstruction in one detector even in the case that other detectors are not operational. To achieve such a fiexibility each detector module should be able to
  • find tracks starting from seeds provided by another detector (external seeding),
  • find tracks without using information from other detectors (internal seeding),
  • find tracks from external seeds and add tracks from internal seeds
  • and propagate tracks through the detector using the already assigned clusters in inward and outward direction.
• where it is appropriate, common (base) classes should be used in the different reconstruction modules.
• the interdependencies between the reconstruction modules should be minimized. If possible the exchange of information between detectors should be done via a common track class.
• the chain of reconstruction program(s) should be callable and steerable in an easy way.
• there should be no assumptions on the structure or names of files or on the number or order of events.
• each class, data member and method should have a correct, precise and helpful html documentation.

AliReconstructor

The interface from the steering class AliReconstruction to the detector speci fic reconstruction code is de fined by the base class AliReconstructor. For each detector there is a derived reconstructor class. The user can set options for each reconstructor in format of a string parameter which is accessible inside the reconstructor via the method GetOption.

The detector speci fic reconstructors are created via plugins. Therefore they must have a default constructor. If no plugin handler is de fined by the user (in .rootrc), it is assumed that the name of the reconstructor for detector DET is AliDETReconstructor and that it is located in the library libDETrec.so (or libDET.so).

Input Data

If the input data is provided in format of root trees, either the loaders or directly the trees are used to access the digits. In case of raw data input the digits are accessed via a raw reader.

If a galice.root file exists, the run loader will be retrieved from it. Otherwise the run loader and the headers will be created from the raw data. The reconstruction can not work if there is no galice.root file and no raw data input.

Output Data

The clusters (rec. points) are considered as intermediate output and are stored in root trees handled by the loaders. The final output of the reconstruction is a tree with objects of type AliESDEvent stored in the file AliESDs.root. This Event Summary Data (ESD) contains lists of reconstructed tracks/particles and global event properties.

Local Reconstruction (Clusterization)

The first step of the reconstruction is the so called local reconstruction. It is executed for each detector separately and without exchanging information with other detectors. Usually the clusterization is done in this step.

The local reconstruction is invoked via the method Reconstruct of the reconstructor object. The deprecated Reconstruct methods with a run loader or a run loader and a raw reader as argument do the local reconstruction for all events. The event loop and the loading of the trees is handled by the AliReconstruction class in case of the Reconstruct methods with two trees or a raw reader and a tree as argument. Only the local reconstruction of the current event has to be performed in these two methods for the two different types of digit input data given by the first argument. The second argument provides the output tree for the clusters. The local reconstruction method is only called if the method HasLocalReconstruction of the reconstructor returns kTRUE.

Instead of running the local reconstruction directly on raw data, it is possible to first convert the raw data digits into a digits tree and then to call the Reconstruct method with a tree as input parameter. This conversion is done by the method ConvertDigits. The reconstructor has to announce that it can convert the raw data digits by returning kTRUE in the method HasDigitConversion.

Vertexing

The reconstruction of the primary-vertex position in ALICE is done using the information provided by the silicon pixel detectors, which constitute the two innermost layers of the ITS.

The primary vertex is reconstructed by a vertexer object derived from AliVertexer. After the local reconstruction was done for all detectors the vertexer method FindVertexForCurrentEvent is called for each event. It returns a pointer to a vertex object of type AliESDVertex.

The vertexer object is created by the method CreateVertexer of the reconstructor. So far only the ITS is used to determine the primary vertex ( AliITSVertexerZ class).

The precision of the primary vertex reconstruction in the bending plane required for the reconstruction of D and B mesons in pp events can be achieved only after the tracking is done. The method is implemented in AliITSVertexerTracks.

Combined Track Reconstruction.

The combined track reconstruction tries to accumulate the infor- mation from different detectors in order to optimize the track reconstruction performance. The result of this is stored in the combined track objects. The AliESDTrack class also provides the possibility to exchange information between detectors without introducing dependencies between the reconstruction modules. This is achieved by using just integer indexes pointing to the speci fic track objects, which on the other hand makes it possible to retrieve the full information if needed. The list of combined tracks can be kept in memory and passed from one reconstruction module to another. The storage of the combined tracks should be done in the standard way (newIO).

The classes responsible for the reconstruction of tracks are derived from AliTracker. They are created by the method CreateTracker of the reconstructors. The reconstructed position of the primary vertex is made available to them via the method SetVertex. Before the track reconstruction in a detector starts the clusters are loaded from the clusters tree by the method LoadClusters. After the track reconstruction the clusters are unloaded by the method UnloadClusters.

The track reconstruction (in the barrel part) is done in three passes. The first pass consists of a track finding and fitting in inward direction in TPC and then in ITS. The virtual method Clusters2Tracks is the interface to this pass. The method for the next pass is PropagateBack. It does the track reconstruction in outward direction and is invoked for all detectors starting with the ITS. The last pass is the track refit in inward direction in order to get the track parameters at the vertex. The corresponding method RefitInward is called for TRD, TPC and ITS. All three track reconstruction methods have an AliESDEvent object as argument which is used to exchange track information between detectors without introducing dependences between the code of the detector trackers.

Depending on the way the information is used, the tracking methods can be divided into two large groups: global methods and local methods. Each group has advantages and disadvantages.

With the global methods, all the track measurements are treated simultaneously and the decision to include or exclude a measurement is taken when all the information about the track is known. Typical algorithms belonging to this class are combinatorial methods, Hough transform, templates, conformal mappings. The advantages are the stability with respect to noise and mismeasurements and the possibility to operate directly on the raw data. On the other hand, these methods require a precise global track model. Such a track model can sometimes be unknown or does not even exist because of stochastic processes (energy losses, multiple scattering), non-uniformity of the magnetic field etc. In ALICE, global tracking methods are being extensively used in the High-Level Trigger (HLT) software. There, we are mostly interested in the reconstruction of the high-momentum tracks only, the required precision is not crucial, but the speed of the calculations is of great importance. Local methods do not need the knowledge of the global track model. The track parameters are always estimated ‘locally’ at a given point in space. The decision to accept or to reject a measurement is made using either the local information or the information coming from the previous ‘ history’ of this track. With these methods, all the local track peculiarities (stochastic physics processes, magnetic fields, detector geometry) can be naturally accounted for. Unfortunately, the local methods rely on sophisticated space point reconstruction algorithms (including unfolding of overlapped clusters). They are sensitive to noise, wrong or displaced measurements and the precision of space point error parametrization. The most advanced kind of local track-finding methods is Kalman filtering which was introduced by P. Billoir in 1983 [ P. Billoir; NIM A225 (1984) 352, P. Billoir et al.; NIM A241 (1985) 115, R.Fruhwirth; NIM A262 (1987) 444, P.Billoir; CPC (1989) 390.].

Kalman filtering is quite a general and powerful method for statistical estimations and predictions.

When applied to the track reconstruction problem, the Kalman-filter approach shows many attractive properties:

• It is a method for simultaneous track recognition and fitting.
• There is a possibility to reject incorrect space points ‘on the fiy’, during the only tracking pass . These incorrect points can appear as a consequence of the imperfection of the cluster finder. They may be due to noise or they may be points from other tracks accidentally captured in the list of points to be associated with the track under consideration. In the other tracking methods one usually needs an additional fitting pass to get rid of incorrectly assigned points.
• In the case of substantial multiple scattering, track measurements are correlated and therefore large matrices (of the size of the number of measured points) need to be inverted during a global fit. In the Kalman-filter procedure we only have to manipulate up to 5 × 5 matrices (although as many times as we have measured space points), which is much faster.
• One can handle multiple scattering and energy losses in a simpler way than in the case of global methods.
• It is a natural way to find the extrapolation of a track from one detector to another (for example from the TPC to the ITS or to the TRD).

In ALICE we require good track-finding efficiency and reconstruction precision for track down to pt = 100 MeV/c. Some of the ALICE tracking detectors (ITS, TRD) have a significant material budget. Under such conditions one can not neglect the energy losses or the multiple scattering in the reconstruction. There are also rather big dead zones between the tracking detectors which complicates finding the continuation of the same track. For all these reasons, it is the Kalman-filtering approach that has been our choice for the offiine reconstruction since 1994.

The reconstruction software for the ALICE central tracking detectors (the ITS, TPC and the TRD) shares a common convention on the coordinate system used. All the clusters and tracks are always expressed in some local coordinate system related to a given sub-detector (TPC sector, ITS module etc). This local coordinate system is defined as the following:

• It is a right handed-Cartesian coordinate system;
• its origin and the z axis coincide with those of the global ALICE coordinate system;
• the x axis is perpendicular to the sub-detector’s ‘sensitive plane’ (TPC pad row, ITS ladder etc).

Such a choice refiects the symmetry of the ALICE set-up and therefore simplifies the reconstruction equations. It also enables the fastest possible transformations from a local coordinate system to the global one and back again, since these transformations become simple single rotations around the z -axis.

The reconstruction begins with cluster finding in all of the ALICE central detectors (ITS, TPC, TRD, TOF, HMPID and PHOS). Using the clusters reconstructed at the two pixel layers of the ITS, the position of the primary vertex is estimated and the track finding starts. As described later, cluster-finding as well as the track-finding procedures performed in the detectors have some different detector-specific features. Moreover, within a given detector, on account of high occupancy and a big number of overlapped clusters, the cluster finding and the track finding are not completely in- dependent: the number and positions of the clusters are finally determined only at the track-finding step.

The general tracking strategy is the following. We start from our best tracker device, i.e. the TPC, and from the outer radius where the track density is minimal. First, the track candidates (‘ seeds’) are found. Because of the small number of clusters assigned to a seed, the precision of its parameters is not enough to safely extrapolate it outwards to the other detectors. Instead, the tracking stays within the TPC and proceeds towards the smaller TPC radii. Whenever possible, new clusters are associated with a track candidate in a ‘classical’ Kalman-filter way and the track parameters are more and more refined. When all of the seeds are extrapolated to the inner limit of the TPC, the tracking in the ITS takes over. The ITS tracker tries to prolong the TPC tracks as close as possible to the primary vertex. On the way to the primary vertex, the tracks are assigned additional, precisely reconstructed ITS clusters, which also improves the estimation of the track parameters.

After all the track candidates from the TPC are assigned their clusters in the ITS, a special ITS stand-alone tracking procedure is applied to the rest of the ITS clusters. This procedure tries to recover the tracks that were not found in the TPC because of the pt cut-off, dead zones between the TPC sectors, or decays.

At this point the tracking is restarted from the vertex back to the outer layer of the ITS and then repeated towards the outer wall of the TPC. For the track that was labeled by the ITS tracker as potentially primary, several particle-mass-dependent, time-of-fiight hypotheses are calculated. These hypotheses are then used for the particle identification (PID) with the TOF detector. Once the outer radius of the TPC is reached, the precision of the estimated track parameters is sufficient to extrapolate the tracks to the TRD, TOF, HMPID and PHOS detectors. Tracking in the TRD is done in a similar way to that in the TPC. Tracks are followed till the outer wall of the TRD and the assigned clusters improve the momentum resolution further. Next, the tracks are extrapolated to the TOF, HMPID and PHOS, where they acquire the PID information. Finally, all the tracks are refitted with the Kalman filter backwards to the primary vertex (or to the innermost possible radius, in the case of the secondary tracks).

The tracks that passed the final refit towards the primary vertex are used for the secondary vertex (V0 , cascade, kink) reconstruction. There is also an option to reconstruct the secondary vertexes ‘on the fiy’ during the tracking itself. The potential advantage of such a possibility is that the tracks coming from a secondary vertex candidate are not extrapolated beyond the vertex, thus minimizing the risk of picking up a wrong track prolongation. This option is currently under investigation.

The reconstructed tracks (together with the PID information), kink, V0 and cascade particle decays are then stored in the Event Summary Data (ESD).

More details about the reconstruction algorithms can be found in Chapter 5 of the ALICE Physics Performance Report [CERN/LHCC 2005-049, ALICE Physics Performance Report, Volume 2 (5 December 2005)].

Filling of ESD

After the tracks were reconstructed and stored in the AliESDEvent object, further information is added to the ESD. For each detector the method FillESD of the reconstructor is called. Inside this method e.g. V0s are reconstructed or particles are identified (PID). For the PID a Bayesian approach is used which is explained in a note. The constants and some functions that are used for the PID are defined in the class AliPID.

Monitoring of Performance

For the monitoring of the track reconstruction performance the classes AliTrackReference are used. Objects of the second type of class are created during the reconstruction at the same locations as the AliTrackReference objects. So the reconstructed tracks can be easily compared with the simulated particles. This allows to study and monitor the performance of the track reconstruction in detail. The creation of the objects used for the comparison should not interfere with the reconstruction algorithm and can be switched on or off.

Several “comparison” macros permit to monitor the efficiency and the resolution of the tracking. Here is a typical usage (the simulation and the reconstruction have been done in advance):

Classes

There are many classes used in the reconstruction. Some of the listed classes are only propositions so far and for some classes there are alternative names proposed.

• AliTrackReference: This class is used to store the position and the momentum of a simulated particle at given locations of interest (e.g. when the particle enters or exits a detector or it decays). It is used for mainly for debugging and tuning of the tracking.
• AliExternalTrackParams: This class describes the status of a track in a given point. It knows the track parameters and its covariance matrix. This parameterization is used to exchange tracks between the detectors. A set of functions returning the position and the momentum of tracks in the global coordinate system as well as the track impact parameters are implemented. There is possibility to propagate the track to a given radius PropagateTo and Propagate.
• AliKalmanTrack and subclasses: These classes are used to find and fit tracks with the Kalman approach. The AliKalmanTrack fixes the interfaces and implements some common function- ality. The derived classes know about the clusters assigned to the track. They also update the information in an AliESDtrack. The current status of the track during the track reconstruction can be represented by an AliExternalTrackParameters. The history of the track during the track reconstruction can be stored in a list of AliExternalTrackParameters objects. The AliKalmanTrack defines the methods:
  • Double t GetDCA(...) Returns the (weighed !) distance of closest approach between this track and the track passed as the argument.
  • Double t MeanMaterialBudget(...) Calculate the mean material budget and material properties between two points.
• AliTracker and subclasses: The AliTracker is the base class for all the trackers in the different detectors. It fixes the interface needed to find and propagate tracks. The actual implementation is done in the derived classes.
• AliESDTrack: This class combines the information about a track from different detectors. It knows the current status of the track ( AliExternalTrackParameters) and it has (non-persistent) pointers to the individual AliKalmanTrack objects from each detector which contributed to the track. It knows about some detector specific quantities like the number or bit pattern of assigned clusters, dEdx, χ2 , etc.. And it can calculate a conditional probability for a given mixture of particle species following the Bayesian approach. It defines a track label pointing to the corresponding simulated particle in case of Monte Carlo. The combined track objects are the basis for a physics analysis.

Example

The example below shows reconstruction with non-uniform magnetic field (the simulation is also done with non-uniform magnetic field by adding the following line in the Config.C:field->SetL3ConstField(1)). Only the barrel detectors are reconstructed, a specific TOF reconstruction has been requested, and the RAW data have been used:

Event Summary Data

The classes which are needed to process and analyze the ESD are packed together in a standalone library (libESD.so) which can be used separately from the AliRoot framework. The main class is AliESDEvent, which contains all the information needed during the physics analysis:

• fields to identify the event such as run number, event number, trigger word, version of the reconstruction, etc.;
• reconstructed ZDC energies and number of participant;
• primary vertex;
• T0 estimation of the primary vertex;
• array of ESD tracks;
• arrays of HLT tracks both from the conformal mapping and from the Hough transform reconstruction;
• array of MUON tracks;
• array of PMD tracks;
• arrays of reconstructed V 0 vertexes, cascade decays and kinks;
• indexes of the information from PHOS and EMCAL detectors in the array of the ESD tracks.