Milestone #17338: Phase 3 Tracking Data Product
Provide an interface for access of reconstructed track information
Similarly as for clusters (issue #14265), add an interface providing access to track information:
- providing access to all the pre-computed information currently available (currently
- no less-than-trivial computation is performed
- access to lower level associated objects; possibly incomplete list:
- clusters (ideally via
- trajectory points ("space points")
- track seeds
- clusters (ideally via
- access to truth information needs to be considered both in principle and in practice
This interface object, with the candidate name of
view::Track, is bound to a main reconstruction action (that is, a track making module).
Careful consideration is needed as how to include vertex information: many tracking algorithms provide vertex information, but vertices can be as well produced by specific algorithms and then associated to tracks, or used as input to reconstruct tracks.
A simple approach is to stick to the same policy as for
view::Cluster (issue #14265) and navigate only elements created with the main tracking module. Then, the other connections would be provided by a higher level abstraction (see issue #14061).
This task is related to the redefinition of the track data products, but it's not fully dependent on it since that one mainly deals with content and storage model, while this one mainly deals with access interface.
#4 Updated by Gianluca Petrillo almost 4 years ago
The first step is the redefinition of the content of
The design and implementation of it is staged:
- the new data structures are plugged into LArSoft with an interface as backward-compatible as possible, to minimise the impact on current code
- the code is transitioned into the new interface; utilities are provided for writing the new objects in a compliant way and for basic navigation
- a complete navigation interface is provided
The delivery time of first stage is constrained by MicroBooNE production, whose official deadline is end of January 2017.
#6 Updated by Gianluca Petrillo almost 4 years ago
recob::Track class interface is as backward-compatible as possible to the old one.
Some data members are been left in there until there is agreement on how to life without them (issue #15453).
Some data members underwent an interface change. These were the only cases where a change was unavoidable.Return value changed from reference to value, because of internal changes:
TVector3instead than a
TMatrixDinstead of a
Typically this is a problem when storing the return into a reference variable, e.g.
The most durable, but less readable, way to fix this is to let the compiler do what it takes:
TVector const& vertex = track.Vertex();
decltype(auto) vertex = track.Vertex();
vertexof whatever exact type
Be aware that this backward compatibility is going to be removed, and all these methods will return a
recob::Track::Vector_tas appropriate. Since these vectors have small differences in the interface with respect to
TVector3, the following code (e.g., the one using
vertex) may have to be fixed.
The same holds for the covariance matrices.
A few methods have been formally deprecated. This means that every time you use one of them in your code, the compiler will give you a warning.
You can and should fix your code to avoid that. Please also report cases where LArSoft still uses them, in case we missed (m)any.
Extent(std::vector<double>&, std::vector<double>&) const: use
Extent()instead; it returns a pair of
recob::Track::Point_t. If your use requires
std::vector<double>, please contact us so that the downstream interface can be extended to support
NumberFitMomentum(): the new protocol requires the presence of as many momenta as there are points in a track trajectory, or none at all. Therefore, use
NumberTrajectoryPoints()to know how many of both there are in the track. Another use in the code was to determine whether there was momentum information available in the track or not. In that case, the usual check
if (track.NumberFitMomentum() > 0)should be replaced by
TrajectoryAtPoint(size_t, TVector3&, TVector3&): the new method
Atin the name!) returns a
TrajectoryPoint_tobject with copies of the direction and momentum. Note that this is different from before, where the returned vector was a direction rather than a momentum. Also, the results are not
TVector3any more, but rather
Direction(double*, double*)has gone through a treatment similar to
Extent(TVector3&, TVector3&)(see above); the return type of the replacement,
Direction(), is a pair of
LocalToGlobalRotationAtPoint(size_t, TMatrixD&)should be replaced by
LocalToGlobalRotationAtPoint(size_t)respectively, which return a rotation matrix (
Rotation_t) that can be used directly on
These members have not formally deprecated yet, and the compiler will not issue any warning when used.
An example of dealing with the
Extent()change and tips for upgrading
TVector3to GenVector vectors (used by the new
recob::Trackinterface) can be found in the From ROOT vectors (TVector3) to ROOT GenVector wiki page.
#10 Updated by Katherine Lato over 3 years ago
as part of a discussion with Erica, Gianluca and Giuseppe, decided that to proceed on this will provide an interface for writing tracks and one for reading tracks that hides connections between tracks in other products.
Giuseppe will take care of the writing interface, Gianluca will take care of the reading interface.