• Created by Unknown User (kutschke), last modified on May 14, 2007

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Summary of SiD Tracking Discussions, May 7-11, 2007 at SLAC

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 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, even if it cannot 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.

I view this as much too confining. We must be able to persist anything we put into the event, even if that information is not useful to the other collaborations. I do agree that track objects and all those downstream of them should be compatible with those used by other collaborations.

New Geometry

The new geometry is well underway but not yet finished. This is the geometry that can describe the detector made of wafers. It can also describe a detector made of cylinders.

RawTrackerHit

We will get LCIO to approve several mods to the RawTrackerHit class and use it as the persistent representation of a single hit pixel or strip.

Needed Changes

  • getDetectorElement(): Gives access to all geometry info.
  • getCellID(): For us this will return a channel ID on the wafer, not a global ID, although the thing persisted will need to be a global ID.
  • return a List of SimTrackerHits not a single SimTrackerHit.

Consequences:

  • Proper merging of backgrounds can only be done at the SimTrackerHit Level.
  • Merging can be done at the RawTrackerHit level but only using digitized pulse heights.
  • The true pulse height ( non-digitized ) is never available to the user.
  • The breakdown of which track contributed how much to the pulse height is never available to the user.
  • The amount of electronic noise (+ or -) in the pulse height is not available to the user.

Recommendation:

People who write RawTrackerHit creators must be reminded to sum contributions before digitization. There is no support for this is in the class system we have specfied so they will need to do it themselves.

Clusters

  • There are two cluster options on the table. A class like Rob's or Rich's stripped down version. Something like Dima suggested. We have not yet made a decsion on this.
  • 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), the container will hold ClusterData.
  • If we go with 1b), 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 bookkeeping which hits remain available for subsequent pattern recognition. What ever solution we choose, it will not modify clusters that are already in the event.

Track Fitters

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
  • 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.

TrackerHits

  • We plan to persist TrackerHits. However they have ceased being useful objects for anything except graphics. They are now the product of pattern recognition and track fitting, not their input as originally envisioned.
  • If we modify TrackerHit to point to cluster information and if we do no persist the clusters it is not possible to run one job to create TrackerHits and later run many jobs to test pattern recognition code.
  • We plan to shoehorn clusters into TrackerHits? We plan to shoehorm TRF hits into TrackerHits. Is this 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.

Configuration and Metadata

  • We have no mechanism for run time configuration. At many points in the discussion we noted that we need one.
  • LCIO allows metadata to be associated with each object stored in the event header. We can and should make use of this to describe how the objects were made: versions of code, run time configuration information.

Old Style Geometries

There are many existing lcio files containing events simulated with the cylindrical vertex and tracking detectors. It will still be possible to read these files and instantiate the geometry representation. Old code will continue to work. Pattern recognition code developed for the planar detectors is unlikely to work with this old files.

  • No labels