Welcome to http://www.bonner.rice.edu/adams/trf++/model_0.2.html
Document updated: 01apr97 1955
Model updated: October 31, 1996.
Previous versions:
Version 1 at http://www.bonner.rice.edu/adams/trf++/model_0.1.html.
This version may be updated futher as implementation continues.
Most of the drawings here were done with the OO design tool Rational Rose although a couple were done with Paradigm Plus.
Here is the original problem statement. A more detailed high level design for the track finding may be found in D0 note 2958/CMS TN96-062 .
Here is our notation using Rational Rose and using Platinum Paradigm Plus .
Here is the top level class diagram with Rose and with Paradigm Plus. The overall system is divided into six class categories and one of is subdivided into another six categories. In this top level diagram many of the classes are supressed. We do show those which have associations outside their class categories.
The surfaces category includes the abstract class surface from which different surfaces (cylinder, plane, ...) are derived. These surfaces define the set of parameters used to define a track. Bounded surfaces are then derived from these.
The tracks category includes the class trevec describing a track vector which includes a surface, five kinematic parameters appropriate to that surface and an error matrix for those parameters. The type of surface specifies the meaning of the five parameters.
The output of track-finding is a list of track objects (or objects from a class derived from track). This class incudes a list of hits and a track vector which has been evaluated using those hits. The class incomplete_track is derived from track and is used during track-finding.
The detector is described by a list of layer objects. Concrete layers are derived from the abstract layer class. Each layer is made up of a list of bounded surfaces. The layer has the responsibility of propagating a track to itself and reporting the crossing status. A list of hits is associated with each layer.
The diagram indicates that we presently support one type of layer: a cylinder composed of one bounded cylinder.
The hits (input measurements) used for track finding are described by classes derived from the hit class. Each hit has the responsibility of returning its value and error and predicting the same for a track. A hit contains a surface used to define the hit parameters. This surface will often (but not neccessarily) be part of the layer pointing to the hits.
We presently support two types of hits: a phi measurement and a stereo measurement (phi+const*z) on a cylinder.
The instructions for finding tracks are found in the paths category. An iterative road-following algorithm is used. Each path includes a layer and algorithms for propagating tracks to that layer, finding hits on the layer, fitting (adding a hit to a track) and checking the fitted track quality. The path also contains a list of child paths indicating where to search next for hits to add to the track.
A path may optionally contain a path stop. Tracks are extended until they reach such a stop and then are added to the path stop list. When all tracks have reached stops filters can be applied to identify and prune tracks which share many hits or have similar fit parameters. Each path includes a list of such filters.
The algorithms discussed above and those used for global control are all contained in subcategories of the algorithms category. All inherit from the algorithm class.
Propagators take a track vector from one surface to another. The track vector and error at the starting surface are used to predict the same at the ending surface. Presently one propagator is provided: it is appropriate for cylindrical surfaces and does not account for variations in the magnetic field, multiple scattering or dE/dx energy loss.
Finders use a track vector to identify nearby hits on a surface. The class diagram shows two concrete implementations. The first simply returns all the hits. The second uses the combined and hit error matrices to define a measure to evaluate the distance between the hit and the track. Presently only the first is implemented.
Fitters use a list of hits to update a track vector. Presently three fitters are provided. The first (fit_nothing) does not modify the track vector. The second (fit_kalman) uses a Kalman filter algorithm to update the track vector using the last hit on the list. The third refits all the hits using the fitter and propagator specified when the fitter object was created.
Checkers are called to discriminate locally against ghost tracks. The checker receives the track vector and the list of hits and returns a nonzero value if they are not suitable for the calling path. Currently two such algorithms are provided. The first always returns zero and so does nothing. The second returns a failure if the number of hits in the hit list is below a threshold set at creation.
Filters are called discriminate globally against ghost tracks. A filter is called with a list of tracks and it can perform comparisons and the flag those which are most likely to be ghosts. The diagram shows three filters. The first (filter_nothing) does nothing. The second flags "tracks in tracks", i.e. those tracks whose hits are an ordered subset of the hits in another track. The third looks for tracks that share some number of hits and then flags one of them for deletion. Only the first two are presently implemented.
This subcategory contains the classes which provide global control of the track-finding process. A global_instructions object is composed of a list of global_algo objects. It sends an initialization message to each of these componenents and then creates a list of tracks which is passed to each component in turn.
We have identified five types of global_algo classes. The first (global_start) creates a single starting track and adds it to the track list. The second (global_find) extends the current list of tracks until all tracks reach a stopping point. The third is composed of a list of stops and it triggers the filters in each. The fourth is made up of filters which it applies to the complete list of tracks. The last (global_finish) is called after track-finding is completed. The first three have been implemented.
The above diagrams provide a static view of our model. The class methods define which messages each object can receive but certain messages are only appropriate when an object is in a particular state. Here we identify some of these states and indicate which messages are appropriate and what state transitions they induce.
We have produced the following state diagrams:
We have identified four persistent states for the incomplete_track class. Objects are created in the no_candidate state from which they can be interrogated for a list of candidate layers or can be propagated to a specific candidate layer. Tracks whose paths are all at active stops or are complete are said to be in the stopped state. A track which is successfully propagated moves into the has_canlayer state where a hit or miss may be added. When a track has no paths remaining or is otherwise invalid, it is moved into the bad state indicating that it may be deleted. The remaining (unnamed) states are transitory.
We have created the following event trace diagrams:
The global instructions object contains the complete instructions for finding the tracks in an event. It is composed of a list of global_algo objects which it initializes and executes each event.
All the tracks in the current track list are extended until they reach a stop or are complete. For each nearby hit, a new track is added and an attempt is made to add that hit to the track.
Whe a track receives a request to propagate to a layer, it passes the request on to the layer which can try each of its constituent surfaces in turn.
A simple algorithm to find nearby hits asks the hit to predict itself using the track and then calculates the distance between the the actual and predicted hits to determine which are nearby. The error matrix is used as a measure of the distance.
A Kalman filter fitter uses the last hit to update the track parameters.
Please send questions or comments to adams@physics.rice.edu.