Geometry building

The geometry building procedure follows the ATLAS tracking geometry philosophy of a static frame of glued volumes, that lead the navigation flow through the geometry,

Attaching a 3D detector geometry

Usually, a 3D detector model geometry exists, which is either native to the full detector simulation (Geant4) or is translated into it. This model, however, is in general too detailed for track reconstruction: navigating through the detailed detector geometry is generally costly and one can profit greatly from a simplification mechanism.

For most part of the track reconstruction, only a surface based description of the detector is needed, in order to allow (surface based) material integration and parametrization/prediction of trajectories on detection surfaces. It is thus necessary that the detection surfaces are described to full detail in the reconstruction geometry (called Acts::TrackingGeometry). This is guaranteed by a proxy mechanism that connects the detection elements (conveniently called Acts::DetectorElementBase) to Acts::Surface object in the reconstruction:

Existing plugins for 3D geometry libraries

Very simple helper methods for 3D libraries exist, they are certainly not optimised, but used for templating:

• Acts::TGeoDetectorElement connects a TGeo volume to a Acts::Surface

• Acts::DD4hepDetectorElement connects a DD4hep volume (based on TGeo) to a Acts::Surface

• Acts::Geant4DetectorElement connects a Geant4 volume to a Acts::Surface

Further extensions exist in dedicated experiment contexts, such as e.g. a GeoModel binding for the ATLAS experiment.

Note

While DD4hep offers a descriptive language with a dedicated extension mechanism that can be used by ACTS to interpret the underlying geometry hierarchy and and structure, there is no such guarantee when having the already as built TGeo geometry in hand. Therefore a dedicated ACTS configuration file based on json can be provided that allows to specify parsing restrictions for sub detectors.

Layer building

Acts::Surface objects that are to be grouped on a layer should be put into a Acts::SurfaceArray and provided to the layer. Certain helper tools exist to ease the translation and create appropriate binning structure: The Acts::SurfaceArrayCreator can create cylindrical, disc-like & planar layers, where the dimensions of the layer are determined by parsing the provided surfaces. Additionally, an envelope covering the surfaces can be chosen.

Note

There exist standard layer builders that are designed to build cylindrical, disk like and planar layers and perform the ordering of the surfaces onto those layers. These builders are called from the top level translation entry points from either TGeo or DD4hep.

Volume building, packing, and gluing

The philosophy of the Acts::TrackingGeometry is a fully connective geometry setup, i.e. Acts::TrackingVolume objects are either pure containers for other contained Acts::TrackingVolume instances (where the contained volumes fully fill the space of the container volume), or are fully attached via the boundary surface mechanism. The boundary surfaces then act as portals from one Acts::TrackingVolume into the next one along the trajectory.

The process to create a fully connected tracking geometry is called glueing. Wherever possible, common boundary surfaces are shared, where this is not possible, they are attached.

For cylindrical detector setups, a dedicated Acts::CylinderVolumeBuilder is provided, which performs a variety of volume building, packing and gluing.

Note

For most cylindrical detectors, there exist automated glueing and geometry building modules that take care of the glueing process.