gdetector examples

Runnable examples showing typical module usage patterns. More...

Collaboration diagram for gdetector examples:

Files
file	gdetector_example.cc
	Example: build detector geometry, load digitization routines, and run a small multi-threaded digitization loop.

Detailed Description

Ownership and lifecycle

Ownership is split between GEMC-managed objects and Geant4-managed runtime state:

• GEMC world objects (e.g. GWorld and related system/volume structures) are owned by GDetectorConstruction and are recreated when geometry is rebuilt.
• Geant4 geometry stores (solids/logical/physical volumes) are managed by Geant4 and are explicitly cleaned before rebuild to prevent stale state.
• Sensitive detectors are created and registered so that Geant4 can invoke them during tracking.
• Field infrastructure is installed per volume; a thread-local field container is used to match Geant4 multi-threaded execution patterns.

Typical lifecycle:

• Construct options (via gdetector::defineOptions()).
• Instantiate GDetectorConstruction with the options.
• Build geometry (Geant4 calls Construct()).
• Install SD/fields (Geant4 calls ConstructSDandField()).
• Optionally reload geometry with reload_geometry().

Architecture

Design notes:

• The detector builder constructs a GEMC world first, then translates it into Geant4 constructs via the G4World adapter.
• Sensitive detectors are created by digitization name, allowing multiple logical volumes to map to a single GSensitiveDetector instance.
• Digitization routines are loaded after sensitive detectors exist, then bound to each detector.
• EM fields are configured per volume using a named field definition and installed via per-volume field managers.

Available Options and usage

The gdetector module aggregates options from multiple dependent modules by calling gdetector::defineOptions(). The current aggregation includes:

• gsystem option set
• g4system option set
• gdynamicdigitization option set
• gsensitivedetector option set

Usage pattern:

• Construct a GOptions instance passing the aggregated definition function:

  auto gopts = std::make_shared<GOptions>(argc, argv, gdetector::defineOptions());

If additional options are added by the module itself in the future, they should be listed in this section and documented at their point of definition.

Module verbosity

The module uses the logger name "gdetector" (see GDETECTOR_LOGGER). Typical verbosity behavior:

• Level 0: high-level run summaries (e.g. geometry tallies, major configuration outcomes).
• Level 1: key configuration steps (e.g. digitization routine creation and successful definitions).
• Level 2: verbose per-volume/per-detector setup details (e.g. SD assignments, field attachment).
• Debug output: detailed diagnostic traces for construction paths and plugin setup decisions.

Examples

The following example demonstrates a minimal usage path including geometry reload and a multi-threaded digitization loop.

• gdetector_example : Multi-threaded digitization example (gdetector_example.cc)

Example snippet:

auto gopts = std::make_shared<GOptions>(argc, argv, gdetector::defineOptions());
auto gdetector = std::make_shared<GDetectorConstruction>(gopts);
auto gsystems = gsystem::getSystems(gopts);
gdetector->reload_geometry(gsystems);

Author

© Maurizio Ungaro

e-mail: ungar.nosp@m.o@jl.nosp@m.ab.or.nosp@m.g