...
This is a summary of some issues that we decided or agreed to leave open. A separate page contains a list of work packages.
I will try to remember to put my personal comments The summary is written by Rob Kutschke and me personal comments are in italics.
Persistency
- We will only persist the official LCIO objects: SimTrackerHit, RawTrackerHit, TrackerHit and the reconstructed track class ( don't know its proper name).
- We will work with LCIO to get small changes made to these objects, but not big changes. We will shoehorn our objects into the defined persistent objects.
- We will not support persistency for other information. Most, but not all, of this information can easily be recomputed.
- We will not persist an organized container of RawTrackerHits.
- We will not persist clusters.
- We anticipate that a future evolution of the reconstructed track class ( perhaps it will be spelled trajectory, not track ), will allow us to persist residuals.
...
- There are two cluster options on the table. We have not yet made a decision on this.
- A class like Rob's or Rich's stripped down version.
- Something like Dima suggested.
- We will add some organized container of clusters to the event. Perhaps along the model Rob suggested, perhaps a different one. If we go with 1b)Dima's model, the container will hold ClusterData.
- If we go with 1b)Dima's model, should we also add a parallel container of TrackCluster objects instantiated with a null helix?
- There are no plans to persist clusters.
- We do not have a solution to the bookkeeping of which hits remain available for subsequent pattern recognition. What ever solution we choose, it will not modify clusters that are already in the event.
...
There are a several track fitters in various states of readiness:
- Norman's TRF.
- Still needs code to load its geometry from the org.lcsim geometry and code to load its hits from org.lcsim clusters.
- Nick's, weight matrix fitter.
- Works on the cylindrical geometry, but not yet on the wafer geometry.
- Caroline's Kalman filter used for muon tracking and could be extended for vertex+tracker.
- Kfitter+SOD Tracker - there is a kalman filter in there but I don't know exactly where.
- We do not have proper output classes for any of these.
...
- We plan to persist TrackerHits. However they
- They have ceased being useful objects for anything except graphics.
- They are now the product of pattern recognition and track fitting, not
- the input to these codes, as originally envisioned.
- If we We intend to modify TrackerHit to point to cluster information and if we do no persist the clusters , in order to provide access to the geometry.
- However we do not plan to persist the clusters. Therefore it is not possible to access geometry from TrackerHits in persisted events. Therefore it is not possible to run one job to create
- the input to pattern recognition and
- run many subsequent jobs to
- develop pattern recognition
- codes.
- We plan to shoehorn clusters into TrackerHits? We plan to shoehorm TRF hits into TrackerHits.
- Is this plan self consistent?
- Maybe, if we add a type field to TrackerHit - which we probably need to do anyway.
Cheaters
A variety of pattern recognition cheaters exist. So far as I know they only work in the barrel and only work for the cylindrical tracker geometry.
...