31.2. Separating Geometry and Analysis

Table of Contents

Why Geometry and Analysis Should Be Separated

In a small test application it is tempting to put everything into a single class or sprinkle analysis code directly inside your geometry definition. This quickly becomes unmanageable once the detector, physics, and analysis become more complex. Separating geometry and analysis means that the description of the detector and the code that interprets the simulation results are independent from each other. Geometry code should define what the world looks like and where particles can interact. Analysis code should observe what happens and turn it into numbers, histograms, and files.

A clear separation makes your simulation easier to extend. You can change detector dimensions, materials, or layout without touching how histograms are created or how ROOT files are written. Likewise, you can try a new analysis method without recompiling or even understanding the geometry details.

Rule: Geometry code defines the world and the detector. Analysis code reads results and writes them out. Do not mix these responsibilities in the same class or function.

Typical Symptoms of Mixed Geometry and Analysis

When geometry and analysis concerns are mixed, several symptoms appear. Geometry classes start to include ROOT headers or other analysis libraries. Output file names are hard coded inside DetectorConstruction. Sensitive detector code writes directly to text files on every step. Histograms are filled directly inside geometry constructors. You may even find print statements in geometry code that depend on event information.

These patterns make refactoring difficult and introduce hidden dependencies. If geometry includes analysis headers you cannot use the same geometry in a different project that uses a different analysis backend. If sensitive detectors handle output files directly, they become hard to reuse and hard to test. Large amounts of I/O from within stepping or hit processing can also slow down the simulation significantly.

By separating responsibilities, you avoid cycles in class dependencies and reduce compilation time. Geometry classes should depend only on Geant4 geometry, materials, and physics headers, not on analysis or external libraries.

Geant4 Components: Where Geometry Belongs

Geant4 already suggests a clean separation through its user initialization and user action classes. Geometry belongs in the implementation of G4VUserDetectorConstruction. This is where you define the world volume, detector solids, logical volumes, placements, and materials. The detector construction returns the top-level world physical volume and nothing more.

If you need to parameterize dimensions or select between different detector configurations, you can give your DetectorConstruction class configuration parameters or provide setter methods. The class should remain focused on building and updating geometry, not on how events are counted or stored.

Sensitive detector classes define which interactions in which volumes are considered as measurements. They translate Geant4 G4Step information into detector hits. Their responsibility is to create, fill, and store G4VHit objects in collections, not to perform statistical analysis or write files.

Geant4 action classes such as RunAction, EventAction, SteppingAction, and TrackingAction provide structured hooks to access information without altering the geometry. Geometry never needs to know how these actions work, it only defines structures that are later observed by actions.

Where Analysis Belongs: Actions and Managers

Analysis code in Geant4 is naturally placed in user action classes and in dedicated analysis helper classes. The G4AnalysisManager is designed exactly for this purpose. It is typically created and configured in RunAction or in a dedicated analysis initialization helper that is called from ActionInitialization.

The responsibility of analysis code is to define histograms and ntuples, fill them when appropriate, and write them to disk at run end. It should depend on hit collections and track information but should never change the geometry.

A common pattern is that EventAction aggregates quantities such as total energy deposited or hit counts per event, while RunAction manages the creation and closing of output files. SteppingAction or sensitive detector classes can push data into hits without knowing how that data will be summarized. A separate analysis helper can then read hits from the event at the end of each event and fill ntuples or histograms.

Rule: Only analysis and action classes should interact with G4AnalysisManager or external analysis libraries. Geometry and materials should never open files, fill histograms, or depend on analysis code.

Clear Interfaces Between Geometry and Analysis

To separate concerns, you need clear interfaces between geometry and analysis. Geometry exposes volumes and detectors through logical volume pointers and sensitive detector assignments. Analysis discovers detectors through names, IDs, or collection names. Communication flows through Geant4 mechanisms, not direct function calls.

A robust approach is to assign clear, stable names to hit collections and logical volumes. Sensitive detectors create hit collections with well defined names. Analysis code, typically in EventAction or RunAction, retrieves these collections by name or ID from the G4HCofThisEvent. The analysis does not need to know how solids are shaped or where exactly volumes are placed. It only needs to know the identity of detectors and the structure of hits.

Similarly, detector IDs can be used to map detector elements to analysis bins or to physical positions. Parameterized volumes and replicas can assign unique copy numbers that analysis can interpret. The geometry defines this ID scheme, while analysis interprets IDs to build spectra, maps, or images.

Configuration Instead of Hard Coded Values

A frequent reason for mixing geometry and analysis is that file names, detector labels, cut values, or selection criteria are hard coded. To avoid this, keep configuration logic separate and pass parameters into both geometry and analysis through a central configuration structure or through macro commands.

Geant4 commands or environment variables can provide run-time configuration, for example which detector version to use, which physics list to load, or what output file name to choose. Your geometry and analysis code should consult these configuration values rather than contain fixed literals.

Using configuration makes it easier to run parameter scans without recompiling and also avoids coupling analysis logic to a specific geometry layout. The same analysis can be applied to multiple detector configurations simply by reading consistent IDs and hit structures.

Sharing Information Without Breaking Separation

Sometimes analysis needs some static information about the geometry, such as the number of detector elements, their dimensions, or their positions. You can provide this information without entangling geometry with analysis.

One option is to store such metadata in a lightweight data structure that is filled by DetectorConstruction and later queried by analysis classes. For example, a simple struct can hold the number of crystals in each ring, or the depth of slices in a water phantom. This struct is independent of Geant4 classes and can be shared through your main program or through a singleton configuration object.

Another option is to let the analysis code query the geometry through Geant4 interfaces. For example, you can access the geometry tree via the G4TransportationManager and traverse volumes to find certain logical names. This keeps geometry in control of structure, while analysis discovers details without needing to modify the geometry code.

Rule: If analysis needs geometry information, provide it through small, read-only interfaces or data structures. Do not let analysis modify geometry or rely on its internal implementation.

Testing and Reuse Benefits

When geometry and analysis are separated, each part becomes easier to test and reuse. You can run a simulation where geometry is built and physics is applied but no analysis is performed, to focus purely on geometry overlaps or physics debugging. You can also test analysis code using artificial hits or simplified events, without building a full detector.

This separation also encourages modular design. A well written DetectorConstruction can be reused across several applications that use different particle sources or analysis backends. Conversely, an analysis module that reads standard hit collections and uses only Geant4 APIs can be attached to many different detectors with minimal code changes.

Maintaining this discipline reduces the risk that changes in analysis accidentally break geometry, or vice versa. It improves clarity for collaborators, since each file and class has a single, visible purpose.

Summary

Separating geometry and analysis in Geant4 is both a design principle and a practical necessity for complex simulations. Geometry classes define world volumes, materials, and detector structures. Sensitive detectors define how interactions become hits. Analysis classes and helpers, working through Geant4 user actions and G4AnalysisManager, interpret hits and track information to produce spectra, images, and output files.

By keeping the interfaces between geometry and analysis narrow and stable, and by avoiding hard coded analysis logic in geometry, you create simulations that are easier to extend, debug, and validate.