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

Compare with Current View Page History

Version 1 Next »

This is the first draft of a list of some of the issues that we are now encountering with the Track class.

  1. I would like to be able to ask for track parameters and covariance matrices that are valid at different locations along the track. Examples of such locations include but are not limitted to:
    • the point of closest approach to the origin
    • just outside of the beam pipe
    • the innermost hit
    • at the outermost hit
    • at the footprint on the calorimeter
    • at an arbitrary hit
    • at an arbitrary surface with a missing hit
    • at an arbitrary location along the track
  2. The class should be rich enough to hold several fits of the same hits, each assuming a different mass hypothesis, e, mu, pi K, proton.
  3. For point 1, how do we report the range of validity of the returned set of track parameters and covariance matrix.
  4. for points 1) and 2), how should the track behave if the exact requested information is not available. Is it allowed to return its best approximation? If so how should that be indicated?
  5. The Track class contains a getReferencePoint() member function. Within SiD people have understood the concept of reference point to have different meanings and code exists for each of the alternate meanings. These codes do not work together.
    Within the LCIO documentation I could only find a cursory definition and I believe that it is wrong.
  6. The Track interface specifies that the track parameters and covariance matrix should be stored as floats. In my experience this is inadequate for some constrained fitting applications.
  7. The class contains methods to access the list of hits on the track. It also needs a method to access the list of expected hits or a list of missing hits, so that one can more easily filter tracks to exclude those with improbable hit patterns.
  8. The TrackerHit interface is not appropriate for stereo silicon strips: one cannot define the (x,y,z) of the hit until that hit is associated with a track. Within SiD we have a plan to go back to the precursor of the TrackerHit to get the required information but I don't really like this.
  9. There does not appear to be a well defined way to get the momentum of the track, because it depends on both the
    Within SiD we have a solution in place.
  • No labels