CLEO III Tracking Overview

In CLEO III, Suez will be used to handle event reconstruction (as well as physics analysis). The modular design of the Frame-Producer/Processor system is exploited to support several interchangeable packages for clustering (SVX and DR cathodes), track finding, and track fitting (some of which are written in Fortran). The resultant Tracking Infrastructure (TI) standardizes the input and output objects at each stage of reconstruction (and hence the interfaces of the algorithms themselves). In this framework, new algorithms can be added easily and transparently.

Depicted below is a highly simplified view of the data flow in the TI. It begins with the raw data read out from the detector and ends with the fitted tracks. Each blue rectangle in the diagram represents an object that holds information about an intermediate stage in tracking. The arrows represent Producers that encapsulate the algorithms that act on these objects to create different objects. Since these objects and algorithms reside in the Frame, subsequent users can easily rerun any piece of tracking in their individual analyses. To navigate the plethora of objects represented by this diagram, users should turn to NavTrack, which provides access to all the tracking information in a single interface.

The details of the TI are described in more detail in the documents here. However, it is worth emphasizing that there exist whole families of algorithms that perform track finding (Doit, Solo, C3tr) as well as track fitting (Klmn3, KalmanFilter, ChisqFitter). Since the inputs to and outputs from these algorithms have been standardized by the TI, one can switch track finders (or fitters) simply by loading a different Producer in one's Suez session. This modularity is reflected in the check boxes on the I wanna page.


Associating Objects in the Frame -- Lattice

Often, one would like to know which input objects were used to generate a given output object, e.g. the hits to which a track was fit. It would be possible to give each output object pointers to the input objects as data members. However, since pointers are not persistent, they cannot be written to storage and reliably read back. Also, such a scheme significantly increases the number of dependencies in the system. It would be nice to associate different types of objects with one another while preserving their independence.

The solution adopted by the TI is to define a templated navigation object, called Lattice, which encapsulates associations of any topology (one-to-one, one-to-many, many-to-many) between any two types of objects. Each object in the Frame contains a unique identifier, which is used by Lattice to forge these links. In addition, Lattice allows each link to hold data describing the connection, such as the residual between a track and a hit.

An example of a Lattice is shown below, where tracks are connected to one or more CC showers, and the link data contains the results of the track-shower matching algorithms.

Here is a Lattice with a different topology that connects a track to its hits.

Lattice is used throughout the TI effectively to chart the history of the tracking algorithms. As code development progresses, the number of different Lattices in the system constantly increases. However, the strain on the end user is minimized by using NavTrack, which handles the extraction of and navigation through the most commonly-used Lattices, such as those between the fitted tracks and its hits.


Components of the Tracking Infrastructure

Below are listed the main components of the TI, presented in the order in which they are created or used during reconstruction (see the data flow diagram above). Modules to be loaded in Suez are given in bold type (type "prod sel <module>" or "proc sel <module>" in Suez). Class names are given in fixed-width font, and the libraries or files with the relevant source code are listed in italics. Header files can be found in $C3_CVSSRC/<library>/<library>/<class name>.h.

Getting data:

Raw data:

Determining the collision bunch:

Calibrated data:

Track finding:

Track fitting:

Particle ID:

The switchboard:

Geometry descriptions:



General Tracking Tools

Please send comments to Werner Sun (