Add local Measurement{1,2,3}D classes

[paulgessinger]

As discussed in the AIDAInnova hackathon during during CW25 2022, we should investigate providing classes for proper local measurements connected to a geometry description. The conclusion was to skip TrackerHitPlane in direct ACTS output, and provide a MeasurementXD to TrackerHitPlane conversion mechanism instead.

Can we use this issue to discuss this further? @gaede @andresailer @vvolkl @andiwand @asalzburger @tmadlener

[tmadlener]

As mentioned during the hackathon already the main concerns from EDM4hep side are the following:

1. Introducing a "data sink" into which users will just start to dump anything, instead of putting it into the EDM properly. We had quite some discussion on how to allow users to store some additional data that does not yet fit the EDM and came up with, what we call UserDataCollection in podio: documentation, UserDataCollection.h
2. Tying the Measurement classes too tightly to ACTS (or any other component that could make use of them).

For the first one I have no clever solution yet, other than discouraging usage via documentation. The second one should be a bit easier to handle by providing some access functionality via some user / ACTS provided enum (or comparable). This would essentially work by mapping enum values to indices, as the access via integer indices will always be possible. I would have to actually sit down and try to come up with an implementation to see where this might fail.

One thing that is not yet entirely clear to me is whether ACTS would also want to persist the Measurement to file or whether it would mainly be used for transient access?

A final thought about the actual implementation: Currently podio does not support building collections of "heterogeneous" types, i.e. it would not be easily possible to put measurements of different dimensions into a collection. Having different types for the different dimensions would be very much preferred for EDM4hep, mainly because an N dimensional "type erased" type, would make the first concern from above even more difficult to handle.

[paulgessinger]

Hey @tmadlener, thanks for the input!

I agree with your first point. Clearly this should be well-defined. However, I do think a local measurement + geometry connection is a reasonably well-defined concept that it doesn't allow "user-data", especially if we tie the axis interpretation to an enum that lives in edm4hep. This doesn't allow "user-data" any more than say the current TrackerHitPlane cov matrix.

I'm still not sure I quite follow your 2nd point. With my proposal of adding a way to specify the local axes at the edm4hep level we break any dependency on ACTS, and the concept of a local measurement + axis definition is quite generic. Aside from this, there's no "proper" way for us to fill TrackerHitPlanes, as we'd have to write redundant information that is then conceptually undesirable, in light of things like sensor alignment, etc.

We could get away without a heterogeneous collection if another type can be set up to reference varying measurements. I.e. if a track state can have a variant pointing either at a 1D, 2D or 3D measurement (etc). If this isn't possible either, we could work around this by having a track state have multiple links, out of which only one is populated. If all of this fails, we'd have to go back to a static fixed size array that we only fill parts of and keep track of the dimension in another variable.

---

On another note, and this is largely a strategy discussion, is that we only need these intermediate EDM types if the chain is supposed to be modular in the end. Ideally, we would want to allow Measurement to be persisted to files. In many use-cases, you want to be able to retrieve the original measurements that created a track, e.g. for truth-matching. If we depart from this, then we can also simplify our work and have ACTS only produce edm4hep tracks as an output, and keep everything else transient. But this then precludes from running, say, the ACTS FATRAS + another tracking component.

On top of this, I think the Track/TrackState EDM will be a whole other discussion anyway. Like I said above, trackstates will have to link back to their local measurements to retain full information. If we don't do this, ACTS tracks can't be read in again as information has been discarded.

[tmadlener]

I'm still not sure I quite follow your 2nd point. With my proposal of adding a way to specify the local axes at the edm4hep level we break any dependency on ACTS, and the concept of a local measurement + axis definition is quite generic.

I think here we probably have the same goal (and potentially even a very similar idea) in mind, but are just coming from two different directions. Maybe this is more easily solved and discussed on an actual example of a Measurement class, where we could then also see how it is used in the end.

We could get away without a heterogeneous collection if another type can be set up to reference varying measurements.

Here we have had a sort of prototype some time ago, but were then sidetracked by other issues: AIDASoft/podio#215. The main issue with heterogeneous collections in podio is that storage really expects homogeneous collections, but this prototype would allow to have heterogeneous collections in memory at least. podio would do the heavy lifting of pulling in the references from the different collections that are actually stored. We would probably have to see how far we can take this approach.