Using TRF++ in D0

D. Adams
02feb98 1850

Within D0, TRF++ is used by a track-finding reconstructor. A reconstructor is an object which updates an event. A track-finding reconstructor extracts clusters from the event, uses them to find tracks and then writes the tracks into the event.

This reconstructor has two major methods: intialization and event processing:

Initialization

This might be part of the constructor or could be separate if there is need to reinitialize (e.g., between runs). The following actions take place:

The D0 geometry is used to build a TRF++ detector object. This object is composed of the layers which will be used for track finding.
The map of paths is built up. These provide the instructions for track finding. The list of paths is used to construct a TRF++ track finder.

Event processing

This is called once for each event to be processed.

Tracking detector clusters are extracted from the event and are converted in TRF++ clusters. Lists of clusters are assigned to the appropriate layers.
The track finder is run and returns a list of found tracks.
The found TRF++ tracks are converted into D0 tracks which are inserted into the event.

Partitioning

It is natural to construct separate objects to carry out the above tasks and, in some cases, to divide these objects into separate pieces for each detector subsystem (CFT, SMT, MUON, etc). Code which is specific to one detector subsystem will reside in a package (or packages) dedicated to that system. There will also be one or packages containing global code.

Geometry

TRF++ defines geometry classes: detectors are made up of layers which are made up of surfaces. The class names are Detector, Layer and Surface. Each subdetector will define its own versions of each of these. There should be a final detector class describing the subsystem (e.g. CFTDetector). The base class Detector provides methods for combining the individual subsystem detectors into one global detector.

Path building

The partitioning of path building is a little more difficult since evaluating the quality of a path will, in general, depend on contributions from more than one subsystem. Each subsystem might provide one or more path builders (e.g. CFTPathBuilder) which take a path map as input and extend it. This needs more thought, much trial and error and almost certainly some redesign of the TRF++ path concept.

Clusters

Each subsystem must decide how to cluster its data and the form in which that data persists. It is likely (but not neccessary) that the TRF++ classes used to represent these clusters will be different from the persistent versions. In any case each subsystem is responsible for extracting its clusters from the event, generating TRF++ clusters and assigning the latter to layers in the detector.

Track finding

The hard work has already been done by defining the detector, path map and clusters. The global reconstructor calls upon the TRF++ track finder to do its work.

Global tracks

As implied by their name, the global tracks are not specific to any one detector. Their definition and persistence is a global concern.

Example

As an example of the above partitioning we show the evolving software for CFT (scifi tracker). The figure shows the package dependencies for global tracking and the CFT subsystem. The global track-finding software is in trf_reco and gtr_evt. The CFT interface to TRF++ is split between trf_reco_cft and cft_trf. This split is such that any code which depends on the event model resides in the former.

Questions or comments to adams@physics.rice.edu.