Experimental Geometry module¶
This module is in production and is under the namespace
The entire geometry setup is based on the following geometry objects
Acts::Surfacedescribing any bound surface object
Acts::Experimental::Portalwhich holds a surface and adds information about attached volumes
Acts::Experimental::DetectorVolumewhich is bound by portals and can contain surfaces and other volumes
Acts::Experimental::Detectorwhich is the top level object holding all detector relevant objects
Memory management, access and const correctness¶
All geometric objects can only be constructed as
std::shared_ptr<T> via dedicated ```Object::makeShared(…)`` factories.
Internally, all constituents are stored as non-const objects and can be accessed as such as long as the geometry is not locked, and the holder object is also a non-const object.
While objects may be stored as
std::shared_ptr<T> internally, their access during navigation is given either to const references (if guaranteed to be existent) or const raw pointers (if optional or part of a polymorphic container).
The Portal object¶
Portals are composite objects of a
Acts::Surface object and additional volume link information which connect a portal to the at least one, but in general multiple volumes it connects. The position and the normal vector of an intersection with a portal are used to determine the next volume and hence the navigation flow through the detector.
When volumes are attached or glued to another, the portal object is usually shared between the volumes, and eventually portals can even be of larger extent than the actual volume they are bounding.
The implementation of a unique, binned or any other volume link can be adapted to the detector geometry by providing a suitablen
The Detector volume object¶
A detector volume has to contain:
a list of bounding portal objects (that can be shared with other volumes)
a navigation state updator as a
Acts::Experimental::SurfaceCandidatesUpdatordelegate, that at minimum is able to provide the portal surfaces for leaving the volume again.
a unique name string
When constructing a detector volume one has to use a dedicated
Acts::Experimental::DetectorVolumeFactory that is provided with a portal generator which allows to generate the portals and set the (yet) existing links appropriately.
Additionally, it can contain:
an optional collection of contained surfaces which can describe sensitive surfaces or passive surfaces (e.g. for material integration)
an optional collection of contained volumes which describe sub volumes, as e.g. chambers or cells
a volume material description
In case the volume contains surfaces and/or volumes, an adequate navigation state updator is to be provided that can resolve surface candidates or portal candidates into the sub volumes. E.g.~if the volume contain a layer with sensitive surfaces, a grid can be used to associate an entry/global position with the candidate surfaces further tested in the navigation.
When building in
Debug mode the containment of objects inside a
DetectorVolume is checked with an
The Detector object¶
The detector object is the holder class of all geometry objects, it has to contain:
at least one detector volume
a name string
a volume finder delegate (as
Acts::Experimental::DetecorVolumeFinder) that allows to uniquely associate a point in space with a contained volume of the detector.
When the detector is constructed, name duplicates are checked for an when failing an
std::exception is thrown.