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.
    • Here is a use case: if you want to identify electrons within jets, you need to remove electrons from photon conversions. To do an optimal job of this requires that the track be fitted as an electron so that the covariance matrices used in the vertexing are optimal.
  3. For point 1, how do we report the range of validity of the returned set of track parameters and covariance matrix. Ideally we should develop this code inparallel with vertexing algorithms that expliot the information.
  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 and they should be stored as doubles.
  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. Is there a more general solution that works for all detector concepts?
  9. Related to the previous point: we should distinguish the concepts of a "hit" and a "hit attached to a track", for which additional information can be computed.
  10. Thinking ahead to alignment. We need a place to store residuals and the errors on the residuals. One should be able to choose if the residual is computed with the local hit included in the fit or excluded from the fit.
  11. There does not appear to be a well defined way to get the momentum of the track, because the algorithm depends on both the track parameters and the magnetic field strength at the point at which the momentum is requested. Within SiD we have a crude solution in place. ( Tony please correct me if the solution is not crude.). If we implement 1), then this becomes even more complicated.
  12. Do we want to discuss the bookkeeping of which hits are already used on tracks and which are free for future pattern recognition. Or is this best left open since it is too difficult to anticipate the needs of all reasonable hit arbitration algorithms?
  • No labels

1 Comment

  1. Hi Rob, a few comments

    1. It would be useful to separate items which require changes to what is stored in LCIO track objects, from features which we can build ourselves on top of this information. For reference here is the current definition of an LCIO track object.
          <block name="Track" major="1" minor="8">
            <data type="int" name="flag">Bit 31 Hits are kept =1, Hits are not kept = 0</data>
            <include subroutine="namedParameters"/>
            <data type="int" name="nTrack"/>
            <repeat count="nTrack">
      	<data type="int" name="type">Type of Track, e.g. TPC, VTX, SIT</data>
      	<data type="float" name="d0">Impact Parameter in r-phi</data>
      	<data type="float" name="phi">Phi of track in r-phi</data>
      	<data type="float" name="omega">curvature signed with charge</data>
      	<data type="float" name="z0">Impact Parameter in r-z</data>
      	<data type="float" name="tanLambda">tangent of dip angle in r-z</data>
      	<data type="float[15]" name="covMatrix"> Covariance matrix</data>
      	<data type="float[3]" name="referencePoint">Reference point (x,y,z) </data>
      	<data type="float" name="chi2">chi**2 of fit</data>
      	<data type="int" name="ndf">ndf of fit</data>
      	<data type="float" name="dEdx">dEdx</data>
      	<data type="float" name="dEdxError">Error of dEdx</data>
      	<data type="float" name="radiusOfInnermostHit">radius of innermost hit used in track fit</data>
      	<data type="int" name="nHitNumbers"></data>
      	<repeat count="nHitNumbers">
      	  <data type="int" name="subdetectorHitNumbers">number of hits in particular subdetectors. TODO need way to define mapping in run/event header</data>
      	<data type="int" name="nTracks"></data>
      	<repeat count="nTracks">
      	  <data type="pntr" name="Track">tracks that have been combined to this track</data>
      	<if condition="(flag&amp;(1&lt;&lt;31)) !=0">
      	  <data type="int" name="n"/>
      	  <repeat count="n">
      	    <data type="pntr" name="TrackerHit"/>
            <data type="ptag" name="this"></data>
      In some cases this may be fuzzy, for instance we could use the multiple sets of existing LCIO track objects to represent different mass hypotheses, or we could extend the Track object to support this directly. If we want to change the LCIO track object we should try to come up with a concrete initial proposal for what we want to store.
    2. The definition of LCIO track parameters and associated reference point is defined here: I think this is a fairly detailed and hopefully unambiguous definition.
    3. I think we have a reasonable solution in lcsim for converting track parameters to momentum, in that we have a field map (even though it is currently a very crude field map) and can use the map at any point to convert curvature to momentum at that point. Do we need anything else?