Cluster structures found by the clusterfinding module TCL are stored and passed to the hitfinding module TPH. It is the goal of this module to locate padrow crossings of parent tracks, and to some extent to characterize the track (in terms of crossing angles and ionization left by the track).
The hitfinding algorithm is more modular than the clusterfinding algorithm described above, allowing improvements in any component of the process. This is important, as it is forseen that improvements in the overall padrow crossing reconstruction efficiency will come from improvements in TPH (although improvements in speed may come as well in TCL). Here, we briefly discuss the main elements in the algorithm, as well as the current implementation of these elements. See Figure 8 for a schematic overview of the TPH algorithm.
Figure 8: Schematic flow chart for hitfinding algorithm that is applied
to each cluster. The default path
is shown. Branch points
for bypassing elements of the algorithm by non-default switch settings
are not indicated.
Because of the high track density, there is a good chance that more than one hit can be found in a given cluster, especially on the inner padrows (see below). The ``Mountainfinder'' algorithm, described below, can be used to search for local maxima in the pad-TDC-ADC space. However, the search is not cheap in terms of cpu cycles (see below), and it is desirable to decide quickly whether a particular cluster is likely to warrent a search for multiple peaks. This decision is the first step in the TPH algorithm. A correlated plot of the RMS of the cluster in pad number and time bucket, shown in Figure 9, shows a clear division between clusters for which the Mountainfinder algorithm found a single hit, and those for which more than one hit was found. The position and orientation of the cut boundary may change with detector configuration (e.g. gas used, drift velocity) or improvement of the multipeakfinder, and so is specified by switch settings.
Figure 9: A simple cut on the rms of the cluster pattern in the
pad and time bucket variables allows a quick decision whether it
is worthwhile to search for many hits in the cluster. The line
marks the cut. Multipeak searches on almost
all clusters lying to the lower left of the cut
resulted in only one peak found.
After the peak(s) are found in the adc-tdc-pad space for each cluster, local hit position information is extracted from the pixels around each peak. See Section 4.2 for details. These local positions are then translated into global x, y, and z coordinates.
Most tracking software is based upon fitting a set of space points (hits) with a functional form believed to represent a track. Thus uncertainties, as well as positions, are calculated and transformed to global coordinates. In order to obtain accurate and meaningful track fit parameters (e.g. particle momentum), it is important that these uncertainties represent an accurate estimate of the width of the residual distribution. Track characteristics that determine the spatial resolution of a hit have been studied. These characteristics include the hit signal-to-noise ratio and the drift distance, which are available at the hitfinder level of analysis. However, the resolution is also strongly determined by track crossing angle, which is not well known until the tracking level of analysis. Therefore, only partial uncertainty information for each hit is stored in TPHIT.(DX, DY, DZ). These uncertainties need to be modified at tracking time. See Sections 4.3 and 6.3 for details.
A measure of the energy lost by the track segment is given by the magnitude of the hit (in ADC counts), and is useful for particle identification. Stored in TPHIT.Q is the amount of this energy loss in keV:
Where 
are the ADC values corresponding to member
pixels of the hit. The gas and detector parameters--
average ionization potential, electronics gain, and gase gain--
which scale
energy loss to ADC value are found in the slow simulator switches.
See [1] for details.
From the shape of the cluster pattern, some information about the crossing angles of the parent track may be deduced. This information may be of use to tracking software in the decision whether to include a given hit in a track. See Sections 4.4 and 6.4 for details.
