Subject: Re: storing a track to the database... From: David Adams Date: Fri, 19 Oct 2001 10:20:52 -0400 To: David Rousseau CC: atlas-database@atlas-lb.cern.ch, reconstruction list I have two comments: one general comment about persistent pointers and one about tracks. I suppose the first is directed to the DB list and the second to the reco list. Skip to the section that interests you. Persistent pointers ------------------ Clearly the problem here is much more general than tracks and clusters but this does provide a good example of the problem that one reconstructed object (track) needs to point back to the objects (clusters) from which it was created. Here I describe a simple strategy for keeping track of these associations. It easily fits into StoreGate, root, objectivity and can even allow events in one type of DB to point to thoise in another (although significant effort is required to dereference these pointers). An important component of the data history that I circulated earlier (http://www.usatlas.bnl.gov/~dladams/data_history) is that each child event data object (EDO) "points" back to its parents. In this case the child EDO is the track collection and the parent is the collection of clusters from the tracking subdetector. Here "points" means that each cluster EDO has an index (within the event or within all of ATLAS) and the track EDO holds that EDO index. The clusters within each cluster EDO are indexed (call these object indices). Tracks hold a list of these cluster object indices. A user of tracks finds the cluster collection using the EDO index and then can find the cluster within the collection using the cluster index. If all ATLAS data (or at least the data for this event) were in a common object DB (perhaps the same federation), the indices can be made to look like pointers. This can also be done under less restrictive conditions. To return to the original question, my guess is that the ESD would be an EDO whose parents include the track EDO. Each ESD track needs one object index to point back to its parent track. Tracks ------- I believe is is useful to distinguish a reconstructed track from a track fit. By the latter, I mean the five independent track parameters and their error matrix at some specified surface or at the DCA (distance of closest approach). A reconstructed track is something that is capable of returning a track fit at any reachable surface. The essence of a reconstructed track is its list of clusters. A track fitter can then use a propagator (which needs the magnetic field and material description) to calculate the track fit at any surface. Having made this distincion it is then natural to define separate classes for the two concepts. TrackFit consists of a surface, a 5-vector and its 5x5 error matrix. RecoTrack consists of a list of clusters (more likely cluster pointers or indices) and may cache track fits at one or more surfaces. The latter data need not be persistent because it is derived from the clusters. In the question below I infer that the reconstructed track is stored in the AOD and a track fit is stored in the ESD. So my answer is yes, they are different classes. Those versed in the Kalman filter methodology will see an alternative to keeping the clusters: one can store the fits or smoothing data at each cluster surface. This is a lot more data but saves the need to refit. The propagator (including field and material) must also be recoverable if we want the fit at an arbitrary surface. If one is only interested in the track fit before the first measurment, then the track fit at that location is sufficient to specify the fit over that range. Now things get a bit fuzzy--over that range the list of clusters and the single fit are equivalent reprensentations of the reconstructed track. The same holds for the fit after the last measurement. These two fits are natural candidates for the ESD. da David Rousseau wrote: Hello Hong, I think we still need an object specific to a track which holds the pointers (or the datalink) to the ClusterCollection (what I called TrackClusters) for 2 reasons: - for each used cluster, one need to hold additional information specific to a track-cluster association, for example a refined cluster position or error computed with the knowledge of the track parameters. - a track typically has 50 clusters (pixel, sct, and trt) and it would be very unefficient to have 50 null pointers when using the AOD. You still have a point that when running from the AOD, one should remember not to use the clusters. I can vaguely imagined that this could be done by having separated interfaces to the track, one which work on AOD and ESD, one which need ESD specific information. To be thought further. Cheers David On Thu, 18 Oct 2001 10:14:06 -0400 (EDT) Hong Ma wrote: Solution 2 would work, sort of, if you decide to include ClusterCollection and TrackCollection in ESD and only TrackCollection in AOD. In ESD, since there is ClusterCollection, the links to clusters in each track are saved. In AOD, since there is no ClusterCollection, the links to clusters in each track can not be saved. The converter should be smart enough not to save NULL links. One can ask the question differently. Should we allow to save a data class differently in different output stream? I don't think it is a good idea to do that, especially for regular data members. Maybe DataLinks are exception. Even then, the users have to be aware of not to access the clusters in the tracks when these objects are read back. If we consider the DataLinks to be different from regular data members, we can imagine a switch for a output stream that will decide whether DataLinks are saved in this stream. But this would be applied to the whole stream. All this assumes that there is no cross-stream reference. This applies to David.R's solution 3 also. Hong. Hong Ma Tel:631-344-2919 Physics Dept, 510A Fax:631-344-5568 Brookhaven National Lab Email: hma@bnl.gov Upton, NY 11973 On Thu, 18 Oct 2001, David Rousseau wrote: Hello Nikos, I'm writing the minutes of the meeting right now, and I'm glad you raise the issue so that hopefully I can write sthg which shows accurately the current understanding. (note to people unfamiliar with these acronyms: ESD is Event Summary Data (similar in scope to good old DST), and AOD is Analysis Object Data (similar in scope to good old mini-DST)) Option 2 is what one would like in an ideal world, but we were told it is not possible. Option 1 would work and allow maximum flexibility, but is really not nice. A 3rd option is closer to option 2: One would have a track class with (1) trackparameters (2) covariance matrix and (3) a (StoreGate) *datalink* to a list of pointers to clusters. This list of pointers to clusters would be held as a separate object, let's call it TrackClusters. So in the transient store there would be a TrackCollection, and a TrackCLustersCollection . Each Track of the TrackCollection will have a *datalink* to the corresponding TrackClusters in the TrackClustersCollection. Then the TrackCollection will go in AOD and ESD, and the TrackClustersCollection will go only in ESD. When the TrackCollection is read back from AOD, the *datalink* to TrackCLusters will be null. So this is close to option 2, except that the designer of the track has to take care write the ESD only information in a separate collection. I hope database experts can confirm that. Cheers David On Thu, 18 Oct 2001 10:40:17 +0200 (CEST) Nikos Konstantinidis wrote: Hi. there was a question/answer in yesterday's reco EDM meeting, but I am not sure I understood the answer clearly. Could I have an answer to the following specific question (from the database people?): Suppose I have a track class which contains as data members (1) track parameters (2) covariance matrix, and (3) a list of pointers to clusters (that make up a track). I run a pattern recognition algorithm and store in the TES a collection of the above tracks. I want to store in the database tracks with all the information (1-2-3), say in ESD, and only (1-2) in AOD. Which of the following statements is true? 1. I have to make a "newtrack" class that has data members (1) and (2) only, make these "newtrack" objects during reconstruction, store them in the TES and then proceed after that to store the first track objeccts (1-2-3) in ESD and the "newtrack" objects (1-2) in AOD. 2. I can specify the way I want my "track" objects stored in the database and then I get (1-2-3) in ESD and (1-2) in AOD. I don't need a "newtrack" class. If later I run a job and want to restore my tracks from the database and want to use AOD, the "track" objects are made transient and the list of hits is left empty. 3. None of the above. (please specify what is the right answer!) Many thanks in advance, Nikos ___________________________________________________________________ This mail has been sent to all members of the list atlas-reconstruction ___________________________________________________________________ A bientot, David ----------------------------------------------------------------------- | David Rousseau courriel : David.Rousseau@cern.ch | | Tel @ LAL : +33 (0)1 64 46 89 72 Fax @ LAL : +33 (0)1 64 46 83 97| | Tel @ CERN: +41 (22) 76 71143 Fax @ CERN : +41 (22) 78350 | | LAL, BP 34, 91898 Orsay Cedex. Bat 200 Piece 142. Labo CNRS/IN2P3| ------------------------------------------------------------------------ ___________________________________________________________________ This mail has been sent to all members of the list atlas-reconstruction ___________________________________________________________________ ___________________________________________________________________ This mail has been sent to all members of the list atlas-reconstruction ___________________________________________________________________ A bientot, David ----------------------------------------------------------------------- | David Rousseau courriel : David.Rousseau@cern.ch | | Tel @ LAL : +33 (0)1 64 46 89 72 Fax @ LAL : +33 (0)1 64 46 83 97| | Tel @ CERN: +41 (22) 76 71143 Fax @ CERN : +41 (22) 78350 | | LAL, BP 34, 91898 Orsay Cedex. Bat 200 Piece 142. Labo CNRS/IN2P3| ------------------------------------------------------------------------ ____________________________________________________________________ This mail has been sent to everyone on the atlas-database list ____________________________________________________________________ ____________________________________________________________________ This mail has been sent to everyone on the atlas-database list ____________________________________________________________________