The routines involved in the track reconstruction are show in
figure ![[*]](file:/usr/share/lib/latex2html/icons/crossref.png){kind=icon}
.
The starting point for the track reconstruction is the routine TKTREV in TKSTEER. It is called from the overall reconstruction steering routine RERECO (and was called from GUTREV in Brahms 2.xx, hence the name). This routine begins with the event initialization, i.e. initialization of the ZEBRA banks for tracking (via TKBBANK) and reset of all pointers and index variables. It then calls routines that transfer all GEANT hits to the tracking hit store, where they can be easily (and independently of the GEANT version) accessed by the local track searches. Other than the GEANT banks, the TK hit bank contains also information on the precision of the hit coordinates, which is subdetector-specific. Therefore it is done separately by a dedicated routine for each subdetector: TKHVTX (vertex detector, CCD or APS), TKHFTD (forward tracking disks), TKHSIT (silicon intermediate tracker), TKHTPC (TPC), TKHFCH (forward chambers). These routines are also responsible for injecting the number of noise hits defined in TKSETR. They are mere interfaces to a generic noise hit injection routine (TKNOISE) and a generic hit readout routine (TKGHIT).
The track reconstruction itself begins with a sequence of calls of local track search routines. Depending on the FFREAD card setup, either ideal pattern recognition routines (``LP_detname'') from DUMPATREC are called, or realistic pattern recognition routines from the respective packages. The realistic silicon track search requires a second routine to be called after the track search itself: it was mentioned earlier that silicon hits are to be passed on to later stages of track reconstruction to allow a later review of the assignment of hits to tracks. However, the SIPATREC package only returns tracks, not the hits which have not been assigned to a track. This is done by TKADDH instead. It should be noted that the track reconstruction routine call statements are surrounded by code which records the time required by the individual packages, allowing a final CPU consumption statistics at the end of a run. After all TEs from the subdetector track searches have been found, a call to TKPUSH adjusts the ZEBRA bank size accordingly, so that all remaining space is available for subsequent steps of the event reconstruction.
The next part of TKTREV is dedicated to book-keeping mutually exclusive TEs. Two TEs are considered mutually exclusive if they either share hits or if hits in one TE are mutually exclusive with hits from the other TE. The former is simply a means to describe that the track reconstruction considers it impossible that a single hit can be part of more than one track. The latter, hit exclusions, comes from the method used to treat strip detectors in the track reconstruction. Hit reconstruction in strip detectors leads to ambiguous hit candidates: true hits and their mirror hits. It is not a priori which hits are true and which are mirrors, but it is clear that out of a given set of a true hit and its mirror hits, only one hit candidate can be used in the final track candidates,whereas the others have to be discarded at some point. This is ensured by marking each set of true and mirror hits as mutually exclusive. Which hit will actually be chosen as true is left to the final (DELSOLVE) stage of track reconstruction, where the best track fits are selected out of all possible combinations suggested by DELSEARCH. To emphasize this, at this stage in TKTREV, exclusions are just registered in a list during a call to TKMKEX; no attempt is taken at this point to resolve any exclusions.
The global track search defines the next section of TKTREV: a call to FSFSTR (in DELSEARCH) runs the subdetector merging processor which creates TSs. A subsequent call to TKAMBI starts the final ambiguity resolver. TKAMBI is the interface to the interface to the C code in DELSOLVE -- a slightly unfortunate construction arising from the idea not to touch the original DELPHI Fortran-to-C interface code in DELAMBI too much. Sole purpose of TKAMBI is to copy all TSs into the TK bank, since DELSOLVE operates on the TK bank exclusively. After running DELSOLVE, TKAMBI also takes care of wiping track candidates that were marked as ``not to be used'' by DELSOLVE from the TK bank.
After the track reconstruction itself was done, a call to TKPERF (if
selected by FFREAD cards) evaluates the performance of the
reconstruction in this specific event. Finally, a call to TKCALI
interfaces the track reconstruction result to the calorimeter code.
TKCALI has become a major piece of code due to completely different
data structures in tracking and calorimetry. First of all, TKCALI
attempts to extrapolate all track parameters to the inner face of the
calorimeter. This is done by using a feature of the DELFIT package:
all surfaces defined in the common blocks FKEXTS and FKEXTY (both in
patchy keep sequence FKEXTS) are used as target extrapolation
surfaces, and the track fit will assign a set of track parameters to
all surfaces that are being traversed by the fitted track. TKCALI
replaces the regular set of extrapolation surfaces temporarily by just
three ones, one cylinder and two end cap planes, which outline the
outer boundary of the tracking detectors. Then all tracks are refitted
with the help of TKREFIT, which dissects every TK into its individual
hits, forms TEs out of those hits and refits the track. Following this
refit, the track parameters outside the tracking detector volume will
be available as extrapolated track parameters on one out of the three
extrapolation surfaces. In the case of the end cap planes, this is
exactly at the inner boundary of the calorimeter. Tracks ending up in
the barrel do however require another step due to the octagonal shape
of the calorimeter. Octagonal extrapolation surfaces, as well as
planar surfaces other than those orthogonal to the beam axis, are not
foreseen in DELFIT. Therefore a second barrel extrapolation surface is
defined for each barrel track. The radius of this barrel is chosen
such that it coincides with the inner calorimeter radius at the 
coordinate where the track leaves the tracking detectors. This is an
approximation which is good for tracks of large momentum, but becomes
increasingly imprecise for small momentum tracks.
Along with the track parameters at the outer end of each track, TKCALI
calculates the Perigee parameters (especially distances of closest
approach to the interaction point in 
and 
, 
and 
).
Both parameter sets are stored in the CALOINPUT keep sequence (see
Table ).
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
of particle 
(true momentum)
