Sorry, this page is kind of lame. I will improve it in my spare time (HA!).

The new hitfinding algorithm is based on the 2-dimensional algorithm
developed for STAR. An html document for the STAR code can be found
**here**.

Here is a step-by-step of the new hitfinder algorithm.

**For each padrow:**

- Find all 2D cluster patterns. Go
**here**for some details. - Remove "noise" clusters, if necessary. This could mean, e.g. throwing
away 1-pad clusters, or clusters with ADC values just barely above readout
threshold. I do not remove any noise clusters currently.
- Remove electron-contaminated clusters. This *is* currently done. It
is hardwired into the code, but will soon become one of the switches. A delta electron will simply TRASH all pixels in its
path as it drifts down to the pad plane. I have seen that
trying to extract hits from an electron-contaminated cluster pattern is
hopeless. I will put a picture of an electron-contaminated cluster here
soon. The delta electron contamination is clearly identifiable as a very
long string (usually 2 pads wide) of high-ADC pixels, typically beginning
at the center of the TPC (where heavy guys go), and ending at the pad plane.
- Then, for each cluster,
**find the hits:**- First, do a "triage cut" (see the appropriate
section in the STARNote) based on the second moments of the cluster distribution in pad and time directions.
This cut gives a quick decision about whether there is likely to be found
more than one hit in the cluster. It is crucial, since multipeakfinding
in a cluster is cpu-intensive, and most clusters do not warrant such
treatment.
- Find 2-D maxima in the pad-time-ADC space. This is done with the
**Mountain Finder**algorithm used in STAR. - Each peak as it is found is
subjected to a "significance test," which is like a 2-D peak-to-valley
ratio, but where the valley is defined is done in a 2-D way. See
**here**for details. In STAR, the severity of this test (the cut on "peak-to-valley ratio") was seen to be the dominant factor affecting hitfinding performance, totally controlling hit purity and efficiency. See**here**for details of the effect of the peak-to-valley cut in STAR. The value of this cut has been roughly optimized by me (Mike), and is about the same as the value in STAR (1.3). It is hardwired, but will soon become a**switchable parameter**in the hits_sw table. -
**Find the location of the padrow crossing that led to each peak (i.e. hit positions):**Here, the idea of running the hitfinder in different

**modes**comes in. If you have not yet read it, take a look at the write-up on**modes**now. The mode determines the level of sophistication one wants to go to in order to extract positional information (at the cost of cpu). It is not yet clear how much one gains as one goes to more sophisticated (and slower) modes.The algorithm goes through each approximation listed below in sequence, stopping at a particular point, depending on the mode. Note that if one goes to approximation 2 (global fitting in 2D space), there is a cluster break-up step one must go through.

**Approximation 0**: One could just take the position of the maximum in the pixel space as the zero-th order approximation to the hit position, and fill the HITS table with that position. This does not save much time compared to the next approximation, however, and is not an option with the current hitfinder.**Approximation 1**: Modes 0 and 1 of the new hitfinder. Here, one does a fit to the**local**pixel pattern around each peak,**ignoring**the presence of the other peaks nearby.**Cluster break-up step**: The next approximation is to fit the cluster patterns globally. There may be 10 or more hits within the cluster, and each hit has 5 parameters that affect the cluster pattern: x and y (the hit position), alpha and lambda (the crossing angles of the track), and an amplitude (dE of the hit). See the STAR cluster/hitfinder STARNote for further details. That means, to do a global fit to a cluster pattern, we must vary 5*N parameters (N=#hits), which can get huge, and eat TONS of time.That is the reason for this step. If a cluster has more than Nmax hits in it (Nmax is a new hitfinder switch), then we go through an iterative procedure to break up the cluster into several smaller clusters, each with less than Nmax hits in them. This can take a lot of time. The simple algorithm is to raise the "zero-suppression" threshold by some amount (currently hardwired, soon to be implemented as a switch), and see if the mother cluster has broken into more than one cluster. Any of the resulting clusters that have more than Nmax hits need also to have the threshold-raising applied to them. It often takes several iterations of raising the threshold step-by-step to break up BIG clusters.

**Approximation 2**: Modes 5, 6, and 10 of the new hitfinder. Here, one is doing a**global**fit to the full 2-D cluster pattern, by varying parameters for each hit. One may try to use information from a (previous) tracker pass through the data to give information about the crossing angles, or not. See the discussion on modes for more details.

- First, do a "triage cut" (see the appropriate
section in the STARNote) based on the second moments of the cluster distribution in pad and time directions.
This cut gives a quick decision about whether there is likely to be found
more than one hit in the cluster. It is crucial, since multipeakfinding
in a cluster is cpu-intensive, and most clusters do not warrant such
treatment.

Back to