Geant4 geometry¶

Celeritas defines mappings to the underlying Geant4 geometry objects for integration in the rest of the code base. The celeritas::GeantGeoParams class manages these mappings. Additionally, like the VecGeom and ORANGE geometry engines, it supports navigation for individual track states (though only on CPU, and without full support for field navigation).

class GeantGeoParams : public celeritas::GeoParamsInterface, public celeritas::ParamsDataInterface<GeantGeoParamsData>¶

Manage and provide access to a Geant4 geometry model.

This can be constructed directly by loading a GDML file, or in-memory using an existing physical volume. The make_model_input function returns the geometry hierarchy including surface definitions for optical physics. The geant_to_id and id_to_geant functions provide mappings between Geant4 pointers and Celeritas IDs.

The ImplVolumeId used by Celeritas is equal to the index of a G4LogicalVolume in the G4LogicalVolumeStore. Due to potential resetting of the geometry, the internal Geant4 ID for the volume may be offset from this index. Currently the ImplVolumeId maps exactly to the VolumeId value: some volumes may be unreachable by the world hierarchy.

In general, the G4VPhysicalVolume is equivalent to the index in its store. However, due to the way Geant4 represents “parameterised” and “replicated” placements, a single G4PV may correspond to multiple spatial placements. Celeritas disambiguates and maps each replicated instance to a distinct VolumeInstanceId (see detail::GeantVolumeInstanceMapper). When querying this ID from an in-memory physical volume, the returned value uses the G4PV’s current state (i.e., the copy number). Similarly, calling id_to_geant on a volume instance ID for a replica volume will change the thread-local state of the G4VPhysicalVolume.

Each SurfaceId maps to a G4LogicalSurface instance, which is ether a G4LogicalBorderSurface (an “interface” surface between two volume instances) or a G4LogicalSkinSurface (a “boundary” surrounding a single logical volume). To ensure reproducible surface IDs across runs, we put boundaries before interfaces, and sort within each set by volume IDs (not by Geant4 object pointers, which is what the Geant4 implementation stores in a table). Surface labels are accessed via the SurfaceParams object, which can be created by the model input returned by this class.

Todo:: Much of the conversion should be factored out into a separate Model class which provides adapters to materials, detectors, and geometry structure.

Runtime interface¶

class GeantGeoTrackView¶

Navigate through a Geant4 geometry on a single thread.

This wraps a Geant4 geometry navigator and volume hierarchy state with the same Celeritas tracker interface. It’s not going to be the most efficient code since the G4Navigator includes a lot of helper functions for managing safety distance, tracking through a field, etc. We also independently store a “celeritas” native position and direction, as well as duplicating the “geant4” position and direction that are also stored under the hood in the heavyweight navigator.

For a description of ordering requirements, see: