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
• gfields option set

Usage pattern:

• Construct a GOptions instance passing the aggregated definition function:

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

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