Welcome to the web pages of the LHCb Track Model Task Force
Charter
The charter, as defined by the Computing Technical Board, is to
- review the new implementation, see Eduardo's pages
- review and provide use cases and requirements
First feedback for the CTB is requested at the CTB meeting 3rd week of April 2005.
Members
Eduardo Rodrigues, Jose Hernando Morata, Gerhard Raven, Patrick Koppenburg, Olivier Callot, Marcel Merk.
A Track in LHCb is/consists/makes available/..., amongst others,
- is a representation of the evolution of the state and trajectory of a charged particle followed throughout the experiment. This representation is in the canonical LHCb Reference Frame. This 'global' representation is build from a set of 'local' representations called states. As such a track can be seen as a collection of states.
- Note that 'local' and 'global' refer to the geometrical region in the experiment, not to the coordinate system. States are represented in the global LHCb coordinate system.
- The states basically represent straight line segments, including a covariance matrix. To achieve a 'global' representation of the trajectory, a set of states parameterized as a function of an 'external' parameter is used. Given the geometry of the experiment, this parameter is choosen to be the position projected onto the nominal beamaxis, i.e. the z coordinate in the canonical LHCb reference frame.
- A Track can be reconstructed from a collection of measurements and a Track can provide a collection of measurements.
- A Measurement is a cluster that has been assigned to a TrackTrack. It contains a measure and a covariance.
- a (persistable) history which documents which algorithm produced the track.
- navigation (back) to (intermediate) track results used as input to create a track, if available.
A State is a collection of parameters that defines a Track in a given (finite) range of space. States are in general the result of fits to a set of measurements.
Track and State evolve in the space following a model (Linear, Parabolic, etc), that is, Track and State can be extrapolated to different locations of the space.
Requirements
In general the interfaces of tools should be 'blind' to the originating algorithm. It is however
understood that the accuracy of the result and the required amount of CPU will depend on the originating algorithm.
Measurement Requirements
- A measurement should be able to give fast access to chi2, residual and residual error.
- It should know which type of cluster it originated from.
- For refitting purposes, the measurement should have access to geometry information. * Q (GR): is it the measurement that needs the geometry, or the projection of the measurement?
- TrackMeasurements can only be 1-dimensional. This has consequences for the use of 2-dimensional measurements:
- It is assumed that a 2-D measurement can be decomposed into two independent measurements. E.g. a "pad" measurement is treated correctly as long as the pad is rectangular.
- The beamspot with an elliptical shape cannot be treated exact
- The r and phi strips cannot be treated as "pads", but only as 1-d measurements
- The z of a measurement is defined by combining the measurement with the trackstate 'at' the measurement, eg. an OT hit which is on a wire which is in a frame which is tilted wrt. the beamaxis, its z defined by the intersection of the trajectory with the (inclined) frame, i.e. by the state.
State Requirements
- The 'state' of the trajectory of a charged particle at an intersection with a plane is described by a state. The state represents the intersection point, the momentum at that point, and their (combined) covariance.
- states are always given in the global LHCb reference frame.
- Given that the location + momentum have a redundant degree of freedom (as the z-coordinate of the intersection is used to parameterize the states), the trajectory is (locally) represented by the (x,y) coordinate of the intersection point, the slopes (tx,ty) of the trajectory with respect to x- and y-axis, and Q/P, where P is the magnitude of the momentum
- A state can be extrapolated to provide a prediction of the intersection of the trajectory with other planes
- (GR:) what if the intersection is beyond the valid range in which it can be extrapolated?
- (GR:) how can an extrapolator know to efficiently extrapolate a state?
- (MM:) There is the possibility that we include the time in the state vector. Do we exclude this in the current model or do we leave it open?
- a state representing a 'straight line' should have Q/P=0. When queried for its momentum eg. p() it should return the IEEE-754 standard infinity, HUGE_VAL defined in math.h, provided this is defined on all LHCb supported platforms.
Extrapolation and Transport Requirements
- One must be able to get a TrackState at any specified location along a TrackTrack, using a tool.
- The location at which a TrackState is requested should be specifiable by
- a plane with specified orientation, in which case the TrackState at the intersection is returned (provided the track intersects the plane)
- possible future extensions to eg. warped planes should be possible in case required
- a 3D point, in which case the TrackState at the location along the trajectory closest to the point is returned. Examples are impact parameters wrt. vertices.
- a line, in which case the TrackState at the location along the trajectory closest to the line is returned. Examples are the (nominal) LHC beamline, lines representing the OT wires (in which case the distance to the wire can be compared to the driftdistance), ...
- The transporation method must be user configurable through settings of options files
- bfield treatment, precision
- material treatment, precision
- The extrapolation should be able to (optionally) specify the accuracy of the obtained 'target' state. This accuracy might depend on the implementation/configuration of the extrapolator.
Track Requirements
- A Track should provide access to the states it contains. These states should be ordered according to their z coordinate. For non-backwards tracks, the order is in increasing z, for backward tracks, the order is in decreasing z. Or, to put in another way, the order is such that those states further from the production point of the track appear after those closer to the production point.
History Requirements
- which algorithm 'found' the track, and which algorithm(s) updated/modified the track. As in the Gaudi Event Model items that are stored in the event store are not supposed to be modified, algorithms that update and/or modify tracks must do this by creating new tracks in different locations in the event store. This information is represented as a unique number (i.e. not as a bitmask) for each algorithm. To avoid having to touch a common headerfile when adding an algorithm, this unique number should be provided by a tool which implements a bidirectional map from number to string. It is the configuration of this tool which specifies the mapping.
- Access to Track(s) that has(have) been used as input to the Track. As the 'input' Track(s ) is(are) in general not persisted, this access will not be persisted (unless this could be done without introducing any size overhead on the persistent side in case of 'no parent available)
Goodness of Fit / Quality requirements
- A Fit is used to reconstruct a Track from a collection of Measurements given a model.
- A Fit should be 'blind' to the aligment algorithm.
- A track should provide 'self contained' access to goodness-of-fit information such as chisquared, dof, prob(chisq) information. This information should be quickly accessible even after readback from the persistent store.
- Information on the status and type of the track fit. Did it succeeded or did it fail to converge? Did the fit determine the covariance matrix, or is it the result of an a-priori parameterization?
- Indication of what kind of/how many hits were used to determine the parameters. This information should also be quickly accessible after readback. As the LHCb-ID which represent the 'clusters' used are be available, and a function counting LHCb-IDs which satisfy a predicate as input can take care of this.
Visualization Requirements
- Tracks should be visualizable by Panoramix
- The class to be visualized should be the same for all tracks
- If for a given type of track some of the member data was not filled by the originating algorithm, it should be possible to calculate it on demand
- If possible this should be extended also to MCParticles
- Panoramix should not require dedicated code/configuration to visualize tracks depending on the originating algorithm.
- it is understood that the accuracy of visualization will depend on the originating algorithm.
- the accuracy/precision of the drawn trajectory should be (optionally) visualized.
- The measurements used by/associated to the track should be indicated
Physics Requirements
- Physics analysis should be independent of the algorithm which produced the track(s).
- It should be possible, as far 'up the foodchain' (or 'down the processing stream') as 'enduser' analysis on a DSTs to refit tracks without having to (re)run the pattern recognition. This is required in order to make it possible to study the effects of eg. different alignments on reconstructed B proper times.
- In addition, one should be able to selectively remove/add measurements before (re)fitting the track
- and reconfigure transportation settings (B-field, material model)
- and use different calibrations/alignments
- The physics code should be agnostic of extrapolation of tracks. It should be possible to delegate this responsibility to the tracking code. It should not need to know explicitly about which states to extrapolate where to obtain states (and their covariance) at any point along the trajectory of the track. It is up to the tracking model to decide which states to use to provide the location (point) and momentum (vector) and their covariance matrix at which
- at which the track intersects a given plane
- is closest to a given line
- is closest to a given point
- buffer tampering should be possible
Persistence Requirements
- The model should allow the possibility of a simple/compact persistent representation (as much as possible independent of external classes such as CLHEP)
- it should be possible to store tracks without duplication of information already present in the RawBuffer (eg. clusters)
- The amount of data made persistent should be in kept at minimum, but it should be enought to recreate a Track and get the best posible State and any location of the detector, and to refit the Track with the possibility of adding/removing Measurements.
- this implies (amongs others) that the complete 'final' output of the pattern recognition should be persisted (including eg. the OT L/R ambiguity).
- the amount of detail persisted should be (user)configurable.
- additional states, measurements
- if measurements are not persisted, they should be recreatable 'on-the-fly' from the list of LHCb-IDs and the rawbuffer information.
- a few pre-defined states may be persisted (closest to the beamline, 1st measurement, ...)
- in no circumstance shall persisted data dependent on conditions data, e.g. beamspot location, ...
- the presence/absence of these states should not impact the usage, but it is clear that the (CPU) performance will be affected.
- the tradeoffs should be clearly documented
Miscellaneous / General Requirements
- The track model must adhere to the general GAUDI design, and the LHCb event model
- separation of data and algorithms
- minimal dependencies between event model classes
- association to the MC truth via channelIDs
- The track model must be described in Xml using GaudiObjDesc gdd.dtd. The header files must be generated from the Xml using the GaudiObjDesc tools
- Intermediate results: the precise representation (state) close(st) to the PID detectors might only be quickly available at the time the PID measurement is performed.
- The distance and chi(squared) compatibility between a track(trajectory) and its measurements should be computable/available
- It should be possible to check the overlap of two tracks by counting the number of shared hits/clusters/measurements, which are identfied by their LHCb-IDs
The location for input, comments and discussion can be found
here
Questions/Remarks/Notes on the implementation
- (GR) should Track::addToStates enforce the ordering of states explicitly?)
- (GR): given that the 'canonical' way of getting states at some location along the track is to use an extrapolator, should a track provide things like positionAndMomentum closestState stateAt physicsState?
- (GR): should setLHCbIDs not take a 'begin' and 'end' iterator instead of assuming the caller happens to use a std::vector?
- (GR): same for setStates
- (GR): should states expose the fact that the internal implementation happens to use a vector? The alternative would be to return a Range in the form of a 'begin' and 'end' iterator. Wouldn't most usage iterate over these anyway?
- (GR:) what is the exact definition of Location ?
- (GR:) are explicit accessors for x, y, z really needed if there is already an accessor for position?
- (GR:) same for tx, ty and slopes
- (GR:) why do position and slopes return HepPoint3D and HepVector3D instead of const HepPoint3D& and const HepVector3D&? Correlated, why not have those as first-class datamembers so that const& can be returned...
- (GR:) why do functions such as propagate take State& as argument instead of 'const State&'? Why not give a const State&, and return a new State, and a HepMatrix (representing the transport matrix) instead of first handing it a state, have it modified in-situ, and then in a seperate call obtain the transport matrix.
- (GR:) does it make sense to split the functionality of ITrackExtrapolator in two, i.e. provide something to explicitly extrapolate states (which is what the 'old' extrapolator did -- call it eg. ITrStateExtrapolator), and have a seperate interface to obtain position, momentum, intersections, from a Track object? In that setup, the second tool could use the first tool when needed...
References
-- GerhardRaven - 03 Apr 2005