Persistent track David Adams March 7, 2002 The inner detector and muon systems all have the goal of finding and fitting tracks. These tracks are persistent data objects so they can be shared, i.e. exchanged though the transient data store. The definition of these tracks can and should be common to all ATLAS detectors. Here are my thoughts on what the track should be. Persistent vs. transient ------------------------ The purpose of the track being described here is to convey information to other systems. This implies similar but different requirements than for tracks used in track finding. It is also desirable to physically decouple the track finding packages from the ATLAS-specific persistent track definition. For all these reasons, the persistent track written to the data store should be distinct from those used in the internals of the various track fitting and finding packages. Here I discuss only the former. Interface --------- In our OO world we begin with a discussion of interface and later discuss what data is needed to support this interface. A track is primarily an ordered list of hits (defined below) and any track should be able to return this list. Anyone wanting to refit a track will want access to this information. Most upstream users are not interested in the hit content but instead want kinematic parameters at some surface, e.g. the face of the calorimeter or a muon chamber or the DCA. We can generalize the notion of surface to return parameters at other useful places such as a vertex or the DCA (distance of closest approach, e.g. to the beamline). We ask that the track be able to return its five parameters and their error matrix at any surface (including generalized surfaces) crossed by the track. The surface defines the meaning of the parameters. Finally the track should be able to return some measure of its quality. One measure is the fit chi-square. Another is the list of active detectors that were crossed without picking up a hit. I call these misses. Monte Carlo comparisons are not included to avoid introducing dependence on simulation software. These can be provided by a separate track matching object. Hits ---- Conceptually a track is made up of a list of hits. A hit is something that provides a measurement which can be used to fit the track. Typically this measurement is interpreted as a position but there are other possibilities such as an energy deposit or time of flight used to estimate momentum. I define a generic hit interface that is appropriate for fitting. A hit provides a measurement vector and an associated error matrix. Typically the vector has one or two entries. The hit has a surface and is able to predict its measurement from the track parameters on that surface. It can also calculate the error in this prediction using the error matrix for the track parameters. This interface is defined in an abstract class which I will call Hit. A reports its list of hits by returning a container of Hit pointers or references. Track Data ---------- Next I describe options for the data that a track must hold to meet the interface described above. We do not want to introduce a physical dependence on the various Hit types and we do not want to take up too much space so we do not hold copies of all the hits (concrete Hit objects). Instead we keep persistent references (DataLinks in parlance of StoreGate) to the persistent objects used to construct the hits. This might be a cluster of strips in the silicon strip detector or a single digitization in one of the muon drift tubes. Or these might be detector identifiers that allow one to access the raw data. We cannot store track fits (five parameters and their error matrix) at the infinity of surfaces crossed by a track. It is sufficient to store the surface and fit at each measurement (hit) surface. A propagator is then used to propagate the track fit to any other surface from the nearest hit surface(s). This takes a lot of space and we may choose to drop some of these measurements with the understanding that an optimal fit will not be available in the vicinity of the corresponding surface. A fitter can always be used to refit the track and recover the intermediate fits when required. D0 uses similar tracks for its inner detector and normally only saves the first and list fits. This allows propagation to obtain optimal parameters inside or outside outside the range covered by the hits. To guarantee the same fits are always returned by a track, we may want the track to hold pointers to its propagator and fitter. allowing optimal propagation. The track should carry the chi-square of its fit. We do not want to rerun the fitter just to recover this number. The track should also carry quality measures derived from the misses. These might include the number of misses and the summary or individual miss probabilities. It might also include ID's for each of the missed detectors. Non-Kalman tracks ----------------- The above is sufficient for tracks fit using a Kalman algorithm. Tracks fit with using least squares with scattering centers will also want to store a larger set of parameters and their error matrix.