More efficient handoff between EDM4hep & ACTS EDM

[tmadlener]

Currently our (Gaudi Functional) algorithms need to consume and produce EDM4hep. This is in general a good idea as it means that we can enforce a certain level of consistency of algorithms and data they can exchange. However, this also means that other "framework like" components like ACTS (or Pandora) have to either be encapsulated within large(ish) Gaudi algorithms or that we will incur several conversions from and to the respective EDMs that they use internally. Especially for tracking, I think it will be important to have it split across several algorithms as some of them (e.g. a (C)KF) are rather generic, but others will be somewhat detector concept specific (e.g. seeding). Hence, there will be multiple algorithms

We will need to figure out an efficient way of dealing with these conversions (or make sure that the cost of conversion is negligible).

[paulgessinger]

We were considering this in ATLAS. There's less of a strong preference to only put writable edm types in the event store but we initially tried common xAOD based intermediate objects.

We eventually moved away from this to avoid the overheads and just put acts types or ATLAS-specific thin wrappers in the event store.

Ultimately, conversion to xAOD now only happens on demand and for debugging or validation purposes where we want IO.

I would probably pursue this approach in key4hep as well.