• Created by Unknown User (kutschke), last modified on Nov 27, 2007

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

Compare with Current View Page History

« Previous Version 2 Next »

Notes from the ALCPG Sim/Reco meeting Nov 27, 2007

Notes by Rob Kutschke. Corrections and comments are welcome.

We discussed how to resolve problems with tracks generated by the FastMC. The root of the problem is the inconsistent use of the concept of a "reference point".

Jan's web page that Norman referenced is: http://confluence.slac.stanford.edu/display/~jstrube/A+New+Track+Interface
I have not yet had a chance to look at it so there is some chance that my notes below contradict it ....

After the meeting I found an old note from Tony that points to an LCIO document that defines the reference point: http://www-flc.desy.de/lcnotes/notes/LC-DET-2006-004.pdf
This definition is consistent with the notes below.

That note from Tony also contains the definition of what is stored in the persistent representation of an LCIO track: From Rob Kutschke

This note is embedded in a broader discussion about tracks rooted at: Evolving the LCIO Track Class

As I understand it, our working proposal is:

  1. All tracks created by the fast MC should be compliant with the track parameter definition in the apidocs for the getTrackParameters() method of the Track interface in org.lcsim.event.
  2. An equivalent statement is that the track reference point is always (0,0,0),even if the track production vertex is far from (0,0,0).
    • Currently, for the fast MC, the reference point is the MC true production vertex of the track. This is causes small subtle issues for tracks from the IP but it causes big problems for tracks from secondary vertices, if people are not aware of this behaviour.
    • Tim Barklow said that he was pretty sure that the code he used a year ago did not behave this way. He would check.
  3. The track reference point is not a point on the track. It is the point against which the 5 helical parameters are defined.
  4. I interpret the above to mean that Track.getMomentum() should return the momentum of the track at the point of closest approach to the z-axis
    • = point of closest approach to the origin in the xy plane.
    • Again this is true even if the track has a production vertex far from (0,0,0).
  5. corollary of 4 is that if I get many tracks that had a true production vertex at the IP, then they will all have different values of Track.getPosition() ( different in all 3 coordinates).
  6. The track interface has no method that returns the (x,y,z) coordinates of the position of the point of closest approach to the z axis.
    • We need to define how people get this info.
    • I think that Jan's Track class has a method to do this.
  7. Tony suggested that a long time ago that the decision was made that getMomentum would return the values at the point of closest approach of the 3D trajectory to the 3D origin (0,0,0).
    • This is not the same point defined above.
    • This is certainly possible, but it seems odd to have gone through all the work of defining what the 5 helical track parameters mean and then having getMomentum() do something totally different.
    • Jan says that his code has the features necessary to return this information and also to return the position at this point.
    • I don't remember if Jan said anything about the error matrix at this point.
  8. This leaves the issue of what to do with tracks that come from production vertices outside of the beam pipe. Norman proposed:
    • Define helical track parameters relative to the above reference point.
    • Smear them using the available parameterized covariance matrices.
    • This is not ideal since the parameterized covariance matrices presume that measurements are present in all layers and that the track originates inside the beam pipe.
    • We do not currently have the tools to do better.
  9. To make his happen requires modifications to the fastmc code. I don't think we decided on who would make this change or if we know yet exactly what changes are necessary.
  10. We need to hear back from Ron Casell and Tim Barklow how these proposed changes will affect their code, for better or worse.
  11. At present there is no handy code to propagate covariance matrices away from the point of closest approach to the z axis.
    When we get this all working we need to summarize it in a working example that exercises the important features.
  12. Caroline has kalman filter code that can address many of these issues and she would like us to evaluate it. I asked for a working example.
  13. I need to understand the interaction of Tracks with ReconTrack, ReconstructedParticle and other Track-like objects
  • No labels