General discussion on design philosophy for mixing reconstruction and analysis

[tmadlener]

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 RecDqdx here as a specific example, but a similar thing also appears in the proposed TOF datatypes (#299).

EDM4hep/edm4hep.yaml

Lines 773 to 780 in bd9f450

	edm4hep::RecDqdx:
	Description: "dN/dx or dE/dx info of Track."
	Author: "EDM4hep authors"
	Members:
	- edm4hep::Quantity dQdx // the reconstructed dEdx or dNdx and its error
	- int16_t particleType // particle type, e(0),mu(1),pi(2),K(3),p(4)
	- int16_t type // type
	- std::array<edm4hep::Hypothesis, 5> hypotheses // 5 particle hypothesis

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/dx or dN/dx with 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.

[tmadlener]

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 RecDqdx above, 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)