Subject: Re: storing a track to the database... From: Alan Poppleton Date: Tue, 23 Oct 2001 02:21:48 +0200 (CEST) To: Nikos Konstantinidis CC: atlas-database@atlas-lb.cern.ch, atlas-reconstruction@atlas-lb.cern.ch Hi Nikos et al, I feel I need to get involved in this discussion since a fair amount of thought has already gone into the iPatTrack package. The design followed a capture of requirements during 1998/9. Perhaps some of you may recall presentations at s/w meetings during this period. The implementation is currently used in the inner detector (iPatRec), muon spectrometer (Moore), for combined tracks (MuonIdentification) and iElRec (presented at Lund but not yet in the repository). A desire for flexibility plus 2 important Atlas features have strongly influenced the adopted design. These features are: 1) Atlas is a rather thick detector such that the vast majority of tracks are dominated by multiple scattering rather than individual detector measurement errors. Even at high luminosity, precise track fitting - following as closely as possible the scattered trajectory - dominates the reconstruction time (at least it did with the Zebra input procedure used during the physics TDR). However applications such as the Event Filter probably don't require the full precision (TrackParameters including covariance computed and stored at various points along the track trajectory) and can run significantly faster if these are neither computed or stored. Conversely applications that need to know these details had better have them stored or they may as well start over from the raw data. 2) The main customers for reconstructed tracks (the ESD) are the calibration and alignment procedures. Their needs dwarf the physics analyses which depend primarily on event/track selection. For example the silicon tracker alignment group are planning to fit about 40K parameters with period O(1 day), ideally with a full set of correlations to profit from constraints such as those from overlapping detectors covering a full circle in phi. To do this they need full reconstruction details for every track above 2 GeV (remember multiple scattering dominates up to 40 GeV). Their requirements include the fitted track parameters, cluster weights and residuals at each measurement layer as well as the means to access the specific detector modules and readout channels. Thus by design, the Track class itself is just a set of pointers to more specific classes containing detailed information. Of course some of these may be null pointers by construction (fast processing) or by data compression (for the AOD): - a vector of local track parameters with covariance - fit quality information (chisquared/prob etc) - hit quality info (unexpected 'holes' in the high efficiency si detectors, short tracks or track segments etc) - truth assoc for m/c studies - a list of generic HitOnTrack objects - active hits representing each cluster or drift measurement plus inert hits giving a record of the material traversed. - a set of pointers to the constituent Tracks, in the case of combined tracks. The data length is dominated by the list* as there are usually between 50 and 60 HitOnTrack's (both in ID and MS - in each case the majority are drift hits from TRT or MDT). The full track parameter vector.size varies between typically 6 in the MS and up to 12 in the ID. So the detailed contents of the HitOnTrack are important from both data storage and persistency viewpoints. Firstly I believe the appropriate Cluster* not to be of any great interest! This is because the raw measured cluster (or drift hit) position needs correction in the track dependent context (position along wire for wire propagation and wire sag corrections, position along strip for non-planar silicon module deformations and alignment rotations). Even the error to be applied in the track fit depends on quantities such as the track angle of incidence; also hits common to several tracks are less precise (we have >10% occupancy in some detectors). None of this detail is known to the original hit/cluster objects - but this forms the bulk of the HitOnTrack data along with fitted residual, readout identifier and material thickness. BTW this design has proved sufficient to enable a modular TrackFitter implementation that needs no knowledge of Atlas specifics apart from the appropriate magnetic field service (an advantage that enables it to work on ID, MS and combined tracks indiscriminately). Furthermore, the Identifier scheme was proposed to handle the unambiguous assignment of hit/cluster information to its corresponding readout channel - in a persistable form (it's really just a string). So what is the objection to using this facility? A weakness of the current implementation is that the traversed material is not fully described in the detctor description - there is no equivalent of the identifier to signify for example a coil in the toroid system. There is not even a facility for picking up the necessary info (radiation thickness, energy loss coefficient). In principle the Conditions db is foreseen for this, but it is difficult to represent the association to a structure that hasn't been designed yet. Two more comments before I finish: 1) I believe the database and datadictionary (Storegate, ADL and/or whatever) should be able to store and retrieve the above track class family design in its entirety (pointers and STL). If this proves impossible, I consider this as a weakness of the database choice rather than of the track design. 2) We also need the concept of Object Evolution. The reconstructed track is in a form satisfactory for alignment programs and the graphical display of interesting events. However typical physical analyses will require the parameters in a different representation (such as 4-vectors). While such needs can and should be provided by TrackParameter methods, frequent recomputation of analysis quantities is something to be avoided. Therefore I propose that the AOD track classes should possess as many of the reco track methods as is feasible, but that the private data should be transformed to the quantities most likely needed during analysis. I guess this could be implemented with a suitable set of abstract base classes. - Alan ____________________________________________________________________ This mail has been sent to everyone on the atlas-database list ____________________________________________________________________