Layerless geometry

Geometry module rosetta stone


Describe replacements of TrackingGeometry, TrackingVolume etc. and how the classes map to one another.


This module is not considered production-ready yet, and is under the namespace Acts::Experimental.


Geometry objects

The entire geometry setup is based on the following geometry 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).

Detailed Description

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.


Fig. 23 Illustration of a shared direct portal between two volumes, the arrows indicate the direction of attachment.


Fig. 24 Illustration of a shared extended portal between several volumes, the arrows indicate the direction of attachment.

The implementation of a unique, binned or any other volume link can be adapted to the detector geometry by providing a suitable Acts::Experimental::ExternalNavigationDelegate delegate.

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::InternalNavigationDelegate delegate, 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.


Fig. 25 Illustration of a planar module endcap detector with a grid holding the indices to the candidate surfaces.


When building in Debug mode the containment of objects inside a Acts::DetectorVolume is checked with an assert(...) statement.

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::DetectorVolumeFinder) 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 and if found a std::exception is thrown. Similarly, when sensitive surfaces are provided and duplicate Acts::GeometryIdentifier objects are found during detector construction a std::exception is thrown. The latter can be avoided by using an appropriate (set of) Acts::GeometryIdGenerator tool(s) which will guarantee some level of uniqueness.


Fig. 26 Illustration (r/z view) of the OpenDataDetector with its sub volumes, portals and contained surfaces.