Present: Herbert Greenlee, Jim Kowalkowski, Marc Paterno, Gianluca Petrillo, Ruth Pordes, Brian Rebel, Saba Sehrish, Tingjun Yang
This is the first discussion on the
recob::Track revision.
The result of these meetings will be an agreed class model that will be then proposed to the LArSoft Coordinators for approval or amendment.
After the exposition of the status, comments were collected.
The bootstrap proposal includes the removal of complex features from the data product class and the splitting of it into multiple data products.
Brian asks what will it be with those complex features. Gianluca's suggestion is that they are moved into non-member functions/algorithms free to access geometry. Brian accepts the approach of a simple "unmutable" class and of detaching the more advanced functionalities.
Brian also requires the track to have geometric information of where it went ("trajectory") and which hits contribute to it.
The policy of filling trajectory is not discussed.
Tingjun Yang points out that a relation between hits and trajectory is necessary. In LArSoft
v04_27_01, PMA tracking algorithm adds that information as metadata in associations. It is implied that a more permanent solution should be pursued.
Herbert Greenlee remarks that there is no data product in LArSoft to store momentum.
After discussion, the consensus converged on:
-
a momentum class representing the momentum at the beginning of the track
-
information stored is just the modulus of the momentum, and its error
-
single precision floating point numbers are sufficient
This class can be stored in vectors parallel to the track vectors they refer to, so that the first momentum object pertains the first track object.
Explicit associations are not ruled out; there may be some cost in terms of performance (no assessment is possible without running jobs), but Brian Rebel endorses them as convenient. Marc Paterno remarks that the use of associations may conflict with requirements of independence from the frmework, while Jim Kowalkowsky recommends not to recreate association-like objects but rather use them directly.
It is also discussed whether the momentum should carry information about the algorithm that generated it. Tingjun Yang reminds that two different momenta are preferred for tracks that seem to and not to stop. The argument is made that the information of the algorithm can be encoded in the data product branch name rather than stored in the product itself. We could not find a convincing use case where we would put momenta from different algorithms in the same collection, nor a case where the algorithm information is needed in such a way that it needs to travel with the momentum itself.
Herbert Greenlee annotates at the end of the meeting that
dQ/
dx is pretty much unusable. Discussion will follow in a future meeting.
The remaining parts of
recob::Track have not been discussed. In particular, there has been no decision about trajectory, connections to hits etc.
Conclusions:
-
advanced functionalities will be detached from the data product class
-
the data product class will have a simple structure [this not a definition]
-
momentum will be detached to live within a class on its own that
-
contains momentum and its uncertainty
-
is associated with a single track (the nature of the association is not finalized yet)
-
refers to the beginning of a track
-
does not carry explicit information about the producing algorithm
There are minutes attached to this event.
Show them.