tmadlener
commented
3 weeks ago We reached a general agreement to keep analysis level quantities out of reconstruction level datatypes as far as possible. In this context analysis level quantities were broadly defined as anything that
- can in principle be reconstructed from other quantities (e.g. the radius of the innermost hit of a track can be calculated from its associated hits)
- require other inputs in the form of particle hypothesis (e.g. as shown in
RecDqdxabove, where the main measured quantity is dQ/dx, and all the others use this as inputs to test different hypothesis) - or very broadly speaking are "convenience" quantities / features that have a (high) chance of becoming outdated
The core parts of EDM4hep for reconstruction should be stable for years and also be independent of considerations regarding data tiers (e.g. REC, DST, ...) and which information might be available in those.
In light of all of this and to move towards EDM4hep v1.0, the following things will happen (concerning this issue, see other points, e.g. in #323, #311, #319)
There are a few places in EDM4hep (including a few places where similar things are proposed, as in #299), where there is a bit of mixing between analysis / interpretation of quantities and "pure" reconstruction. This issue should serve as a discussion board to figure out if we are OK with this, or if we want to / can come up with a different approach.
Using
RecDqdxhere as a specific example, but a similar thing also appears in the proposed TOF datatypes (#299).https://github.com/key4hep/EDM4hep/blob/bd9f45039149781a9c54799a6d03df56b1b5ed49/edm4hep.yaml#L773-L780
That stores an array of 5 hypothesis for different particle types. This is rather strongly mixing the reconstruction of a value, in this case
dE/dxordN/dxwith its later interpretation.There is nothing strictly speaking against this, but IMHO it mixes reconstruction and analysis rather heavily and it might be better to split these apart slightly.