The old Track
The current Track interface suffers from the following problems
- Inconsistent accessors: A complete representation is given by the reference point, the POCA on the track to the reference point and the momentum at that point. However, org.lcsim.event.Track only provides reference point and momentum.
- The Track parameters are only accessible by index
What is more important is that the only implementation of Track that exists in the main trunk, ReconTrack, adds the following problems
- The Track parameters are always evaluated at the origin
- the reference point of the Track is therefore (0, 0, 0), but getReferencePoint() returns the same point as getOrigin of the particle that the track was instantiated with.
- The Parameters of the Track are never swum to the reference point and therefore the track parameters are therefore wrong by design for all particles that don't come from the origin
This has the result that you cannot reliably swim the Track to a given point. Because the reference point for the track is 0, the Swimmer claims that the tracklength to the origin is 0. However, since the Track has been instantiated from a particle that did not originate at the IP, the track parameters do not actually correspond to the origin.
In other words: The POCA on the track to the IP results in the wrong point.
The result of this can be seen in 
, 
A new Track
Interface Design goals:
- The Track should make sense independent of the detector, it should be self-contained
- You should be able to reliably swim the parameters to a given point
- You should be able to reliably translate the track parameters to space and momentum and back
The interface to the FastMC should be flexible enough to allow switching the smearing on/off.
For this to work many of the existing classes had to be refactored to use common methods to ensure consistency. Furthermore the current HelixSwimmer has to rely on the implementation of Track being broken in the same way as ReconTrack...