An introduction to TRF++ may be found at http://www-d0.fnal.gov/~dladams/trf.
The description below includes links to the code contained in this package. This version of the code may not be the most recent.
TRF++ package trfbase defines the base classes for manipulating tracks.
The physical components include:
Their dependencies are illustrated in the physical dependency diagram.
The (not up-todate) class diagram shows some of the classes and their relationships.
This package depends on the following external packages:
The classes defined in the above components are described below. Unless otherwise indicated, each class is described in the component of the same name. The descriptions here are brief. See the heaser files for details.
Pure surfaces define the five track parameters associated with the surface. Operations requiring interpretation of the these parameters are carried out by the appropriate surface class. These operations include:
Each concrete surface must have a well-defined convention for defining the forward and back directions for a track. If the track parameters are sufficient for ascertaining this direction, then the concrete surface should override the method get_direction.
Bounded surfaces provide the capability to determine if a track at the pure surface is in bounds. Both pure and bounded surfaces return objects of type CrossStat in response to inquiry about the status of a track at the surface. This object contains information about wheher and how the track crosses the surface.
Surfaces provide run-time type information via methods get_pure_type and get_type so that users holding pointers to the base class can verify the actual type of the object. These methods return a unique address corresponding to the type. The first specifies the pure type and the second the bounded (full) type.
The second two components describe classes of the same name. A VTrack contains a TrackVector and a surface and could, for example, be used to describe a Monte Carlo track. It contains an attribute for specifying the direction of a track relative to the direction of its surface. This attribute is only relevant if the track parameters are not sufficient to make this specification.
ETrack derives from VTrack and adds an error matrix and is thus suitable to describe a fitted track. Note that both of these classes describes the state of a track at a fixed surface. They do not provide any method for propagating tracks to another surface.
In addition, Monte Carlo tracks are rpresented by MCTrack which is simply a typedef for VTrack.
Propagator is the abstract base class which defines the interface for any propagator. It derives from Algorithm. A propagator can propagate either a VTrack (i.e. just the vector) or an ETrack (both vector and error matrix). The propagation may be in a specified direction or a default defined by the derived class. Thus there are four different propagation methods to handle the combinations.
PropNull is a propgator which does not modify the track. It returns success if the destination surface matches that of the track.
PropDirected derives from Propagator and provides a simple implementation of the default direction. It remains abstract, lacking the implementation of VTrack and ETrack propagation in a specified direction. Concrete propagators may derive from PropDir if a more sophisticated implememtation of the default direction is not required.
PropDispatch maintains a map of propagators indexed by their initial and final surface types. Each of the usual propagator methods invokes the ame method for the appropriate registered propagator.
The component HitVector defines three classes:
The measurements themselves are described by class Hit using these classes. The model for describing hits is a little complicated to allow for merged clusters, i.e. nearby signals from different tracks (or one track and noise) which cannot be unambigously resolved.
The class Cluster represents a cluster of signals in the detector which cannot be unambigously disassociated from one another but are independent of other clusters. The latter meaning that the track crossing(s) which gave rise to one cluster do not contribute significantly to any others.
A cluster takes a track (ETrack) as input and generates a list of hits. The method also requires a reference-counting pointer to itself as input so the pointer can be copied to each of the hits. There is a special class ClusterPtr to describe this pointer. This pointer class also provides a simpler interface for fetching the hits.
A hit is able to provide a measurement along with its error and a prediction for this measurement along with its error and derivative with respect to the track. In general any or all of these quantities may depend on the input track. The number and types of hit generated by the cluster may also depend on the input track parameters and errors.
Hits can be modified by update with a new track, typically a track refined by fitting with hits from other layers. The output of a hit object must be uniquely determined by the track used in its last update. It cannot depend on any preceeding updates. An update with the track intially used to construct the object must reproduce the intitial state. A hit has a pointer to its parent cluster and may make use of its parent to carry out an update or evaluate requested output.
McCluster is an abstract subclass of Cluster which maintains a list of Monte Carlo track indices. Concrete subclasses which represent clusters for Monte Carlo data can inherit from McCluster instead of cluster. Note that the list of MC ID's can only be defined in the constructor of McCluster so these must be provided in the constructor of the concrete cluster.
Class VTrackGenerator produces VTrack objects at a specified surface with track parameters within a given range. The surface and range are provided as arguments to the constructor.
Class HitGenerator is an abstract interface which takes a VTrack and produces a cluster at a specified surface. The cluster may then be used to generate hits in the usual manner. Each type of cluster/hit is expected to provide its own concrete implementation of this class.
Abstract base SimInteractor does the same for a VTrack.
SimInteractorRegistery calls a registered SimInteractor based on the surface.
Questions or comments to dladams@fnal.gov.