feat: Gen3 DD4hep construction#5193
feat: Gen3 DD4hep construction#5193paulgessinger wants to merge 55 commits intoacts-project:mainfrom
Conversation
f4d3d88 to
8538d86
Compare
|
From my point of view, I am pretty happy with the state of this. I have exercised a few of the geometries we have in k4geo in key4hep/k4ActsTracking#36 and at least for me the still existing amount of boilerplate is acceptable (and probably also necessary) given the layouts of the tracking devices we have. |
| /// @tparam BackendT Geometry backend satisfying @ref detail::BlueprintBackend. | ||
| template <detail::BlueprintBackend BackendT> | ||
| class ElementLayerAssembler { |
There was a problem hiding this comment.
Where would a layer assembler for planar layers / testbeam like setups go in this new scheme? In the original API we simply introduced a PlaneLayerHelper similar to the original LayerHelper for that. Should that go into a dedicated Assembler or is this one general enough to also accomodate a LayerType::Planar, you think?
Tagging @RainWindWang as well here, since she did the original implementation.
There was a problem hiding this comment.
I would think that it should scale to plane layers, it only needs to produce the corresponding container type. But I agree that this is something we should explicitly foresee!
b17a972 to
9acc9b5
Compare
it also gets the layer node as a shared pointer now
Necessary for gcc13 (Ubuntu24)
tmadlener: Lifted from previous work on the old API proposal design
tmadlener: Lifted from earlier work done on the old API design proposal
Do not prescribe CylinderContainers
Some helpers and at least some of the necessary disambiguation
Move ODD TGeo constants/layer binning logic into the DD4hep builder path and remove the generic TGeoBackend constant-provider plumbing.
fbda51b to
65e8d40
Compare
No description provided.