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
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
- Cg3: standalone Geant-based detector simulation -- soon to be
replaced by Cleog-in-Suez.
FastMC:fast hit-level Monte Carlo
(modules: FastMCProcessor +
- OnlineDelivery: read raw data from EventBuilder
- Raw data parser:
- Access the readout from each subdetector
(module: RawDataProd). This is
unnecessary when using FastMC.
- Raw data objects for each subdetector:
Determining the collision bunch:
- CESR bunch structure (module: CESR).
- Determine the t0 of the event
- Raw data calibrators:
- Calculate the quantites useful for tracking from the raw data --
requires constants access.
- DR drift function (module: CDOffCal).
- Convert ADCs into drift times, logical address
into layer/wire numbers
- Cluster hits on cathode pads
- Cluster hits on SVX strips
- Except for CDOffCal, these are all unncessary when using the
FastMC, which generates CalibratedHits.
- Calibrated data objects:
- Track finders:
- Doit: CLEO II/II.V DUET algorithm modified for CLEO III
- Solo: CLEO II/II.V TRIO algorithm modified for CLEO III
- C3tr: C++ algorithm based on clustering track segments found in
DR superlayers (module: C3trProducer).
- DR track extrapolation to find SVX hits
- Standalone inner tracker
- Seed tracks (input to the final track fitters):
- TRSeedTrack (lib: TrackRoot):
preliminary estimation of the track parameters, used
as a seed for the final track fitter.
Lattice linking TRSeedTracks and CalibratedDRHits.
Lattice linking TRSeedTracks and CalibratedCathodeHits.
Lattice linking TRSeedTracks and CalibratedSVRphiHits.
Lattice linking TRSeedTracks and CalibratedSVZHits.
(lib: TrackRoot): quantities that describe the quality
of the seed track, like the chi-squared of the preliminary fit.
- dE/dx: I dunno... ask RAB.
- Rich: getting there...
NavTrack: a navigation object that provides easy
access to (almost) all the tracking objects in the Frame
- Passive geometry:
The geometry of the passive detector elements is described
with the DetectorGeometry package. Each subdetector's geometry is contained in
a DGDetectorStore, with which users may traverse the hierarchy
of material volumes.
- Beampipe assembly and REQ magnets (module: IRGeom).
- SVX wafers, carbon fiber support tube, diamond support structures
- DR inner tube, wedding cake, conical endplate, outer skins
- Rich radiator crystals, expansion volume, LiF windows, drift chamber,
readout pads (module: RichGeom).
- Crystal calorimeter (module: CcGeomProd).
- Muon chambers?
- Active geometry:
Unlike the passive geometry, there is no consistent method for describing
the sensing elements of each subdetector. In general, however, users
will extract from the Frame "active element stores" that provide
the locations and other geometry parameters of individual measurement
devices, e.g. DR sense wires, SVX strips.
- Detector calibration.
- SVX and DR alignment.
General Tracking Tools
I wanna page:
custom-generated code snipets and Tcl scripts.
used by FastMC, KalmanFilter, ChisqFitter,
Please send comments to Werner Sun