Add in-memory DD4hep to Acts Geo Gen3 conversion

[tmadlener]

BEGINRELEASENOTES

• Rework the ActsGeoSvc to do the conversion from DD4hep to ACTS Gen3 geometry in-memory via the ACTS blueprint API. This does not yet update any tracking functionality, it only adds geometry conversion
  • Populate a CellID to Acts::Surface mapping on the fly after geometry conversion.
  • Provide a uniform & constant magnetic field taking the value at (0, 0, 0) from the DD4hep geometry
• Provide an extensible way of adding more detectors. For now a subset of detectors living in k4geo is handled
  • MuonCollider: MAIA_v0, MuSIC_v2
  • FCCee: ILD_FCCee_v01, ILD_FCCee_v02, CLD_o2_v08, CLD_o2_v07
  • LUXE: LUXE_v0 (lives in https://github.com/LUXESoftware/luxegeo)

ENDRELEASENOTES

• Needs feat: Gen3 DD4hep construction acts-project/acts#5193
• Includes Fix several deprecation warnings from Acts #45

This is a work in progress with the main purpose of being able to share ongoing efforts. So far the efforts focus on getting (parts) of the MAIA_v0 geometry conversion tested and evaluated against upstream work happening at currently living on https://github.com/paulgessinger/acts/tree/feat/dd4hep-gen3

For the MAIA_v0 geometry, this needs key4hep/k4geo#549

[paulgessinger]

Do you think something like this should exist at the library level?

[tmadlener]

I am not entirely sure. I don't see a way to make this general enough to be useful without inventing another semi DSL just for this purpose. This specific thing works for our case, where there is one (or a few) endcap layers that protrude into the cylinder formed by the outermost barrel layer(s). However, we currently only have this nesting once (in a subdetector). As soon as we have, e.g. two different levels of protrusion it no longer works. The way out would be to simply call this thing twice with different configurations, but then one would have to potentially add more config, e.g. to allow for "empty" layers.

Given that it's fairly straight forward to build this on our end on top of the proposed API, I would keep it in "userland" and see if it's common enough there to merit upstreaming later.

[tmadlener]

With the changes in paulgessinger/acts#33 we now also support planar geometries, like LUXE

[tmadlener]

Key4hep nightlies are building, only tests are failing now. Looking into them. This is ready for review in any case.

[tmadlener]

Most of the geometries do not yet use the "hierarchical" drivers that are assumed for most of the tests here. These are done in key4hep/k4geo#579

I could switch the conversion code to work with the older versions and then we switch back to this version once we have them in place.

[tmadlener]

The artifact uploading will eventually have to move to the upstream action. See also the discussion in key4hep/key4hep-actions#39

[tmadlener]

This is now in a quite decent stage from my point of view. It converts the advertised geometries as they currently appear in k4geo (nightlies). I have checked the produced .obj dumps that can be produced via Acts and the geometries look sensible. The minimal tests for propagation also serve as a (non-exhaustive) check that navigation through them also works.

The one thing that is not yet full working here is the SET for the ILD_FCCee models (see inline comment). I would be happy with leaving that as it is and fixing it later.

I am fairly happy with the utility functionality in the Blueprints namespace in DD4hepBlueprintConstruction.cpp now. There is not too much duplication and many of the detector specific details can be handled by simply defining a dedicated TrackerSpec. This should also make it possible to add more geometries rather easily in the future. The naming of the namespaces that contain the populateBlueprint functions is up for debate, but an entirely internal detail so this can also be fixed / generalized later.

I will update #49 with some tests for all the converted geometries to establish basic tracking. We can discuss how we want to proceed with these PRs. I would have a preference to get at least some basic functionality in on which it is then possible to iterate, but we can discuss this.