GATE Version 10: Python-Enhanced MC Platform

• GATE Version 10 is an open‐source Monte Carlo simulation platform for medical physics that integrates a native Python interface with Geant4’s robust physics engine.
• It employs a modular C++/Python architecture—comprising layers like g4_bindings, opengate_lib, and opengate—to support seamless embedding, extensibility, and parallel execution.
• The framework features time‐aware source generation, advanced variance reduction techniques, and integration with AI-driven models to enhance simulation accuracy and performance.

Searching arXiv for the cited GATE 10 papers and closely related records. GATE version 10 is a major evolution and re-implementation of the long-standing Geant4-based Monte Carlo application for particle and radiation transport simulation in medical physics. Built on Geant4, it replaces the legacy macro-based or static-input workflow with a native Python user interface while preserving direct linkage to Geant4 under the hood, and it introduces embedding as a library, enhanced parallel execution, and a modernized collaborative development framework. The two companion papers divide the subject between feature-level presentation and architectural analysis: Part I emphasizes development, new features, algorithms, supported platforms, and applications, whereas Part II details the modular C++/Python design, time-aware source generation, scoring internals, and extensibility mechanisms (Sarrut et al., 14 Jul 2025, Krah et al., 14 Jul 2025).

1. Scope and defining characteristics

GATE 10 is presented as an open-source Monte Carlo simulation platform for medical physics, with particular emphasis on PET, SPECT, radionuclide therapies, prompt-gamma timing systems, proton and ion therapy, brachytherapy, linac phase-space modeling, and optical detector R&D (Sarrut et al., 14 Jul 2025). Its core defining change is the adoption of a native Python API in place of the legacy macro syntax, coupled to Geant4 through wrapped C++ components rather than through an external front-end detached from the transport kernel (Sarrut et al., 14 Jul 2025).

A central characteristic of the release is that the Python layer does not replace Geant4’s transport or physics machinery. Rather, Python calls construct and initialize corresponding C++ Geant4 objects, and the system retains full back-compatibility of Geant4 physics parameters. This addresses a common misunderstanding that a high-level Python interface necessarily implies reduced access to Geant4 internals; the architecture instead aims to expose Geant4’s functionality with less configuration friction (Sarrut et al., 14 Jul 2025).

The release is also defined by a shift in deployment model. GATE 10 can be used not only as an application but also in an “embedding-as-a-library” mode, imported directly into Python or C++ applications. This suggests a transition from a standalone simulator toward a simulation framework intended for integration into treatment-planning software, reconstruction pipelines, and AI-coupled workflows (Sarrut et al., 14 Jul 2025).

2. Software stack and execution architecture

The architecture is described as three tightly coupled layers: g4_bindings, opengate_lib, and opengate. In Part II, g4_bindings uses pybind11 to wrap key Geant4 classes such as G4RunManager, solids, and physics lists, so that Python code can instantiate and configure Geant4 objects as if they were native Python classes. Trampoline classes permit Python subclasses to override virtual C++ methods and receive callbacks from the Geant4 execution flow (Krah et al., 14 Jul 2025).

The second layer, opengate_lib, comprises approximately 100 C++ classes implementing performance-critical components, especially actors for scoring and recording, sources for primary generation and timing, and hooks into Geant4’s SteppingAction and EventAction loop. The third layer, the pure-Python opengate package, registers every GateObject with manager classes and resolves inter-object references before launch. The architectural description names SourceManager, VolumeManager, PhysicsManager, and ActorManager, whereas the feature-level description refers to a public API organized around GeometryManager, PhysicsManager, SourceManager, and ActorManager; both descriptions emphasize a manager-centric configuration model (Krah et al., 14 Jul 2025, Sarrut et al., 14 Jul 2025).

The separation between configuration and execution is implemented through an engine layer consisting of SimulationEngine, PhysicsEngine, VolumeEngine, ActorEngine, and SourceEngine. When sim.run() is invoked, these engines construct the corresponding Geant4 objects in a new, optionally spawned, process, launch the Geant4 run manager, and then tear the objects down so that the Python interpreter can continue. Object lifetime management uses a Python GateObject.close() protocol and pybind11 nodelete flags to avoid double frees and stale references (Krah et al., 14 Jul 2025).

This architecture is also what enables embedding. Instead of calling a monolithic executable, a host application may instantiate a Simulation, add geometry, sources, physics, and actors through the library API, initialize, and run. A plausible implication is that the same simulation kernel can support both interactive notebook-driven prototyping and incorporation into larger software systems without a separate serialization layer.

3. Python interface, Geant4 abstraction, and time-aware sources

The user-facing change most visible in GATE 10 is the move to pure Python scripts. The software is described as fully scriptable and extensible in Jupyter notebooks or IDEs, installable with pip install opengate, and free of macro-compilation steps. Part I also states that all Geant4 classes relevant to volumes, materials, physics lists, and scorers are wrapped through a custom binding layer independent of Boost.Python, while Part II specifies pybind11 for the architectural implementation (Sarrut et al., 14 Jul 2025, Krah et al., 14 Jul 2025).

GATE 10 encapsulates Geant4 regions, production cuts, step limiters, and physics lists behind concise Python methods. A request such as setting a 3 mm electron range cut on a volume causes PhysicsManager to create or retrieve a Region, assign a G4ProductionCuts container, and call SetProductionCut internally. Likewise, optical physics and user limits are activated through direct Python calls without requiring explicit management of G4Region or G4UserLimits objects (Krah et al., 14 Jul 2025).

A key architectural innovation is the time-aware generation of primary particles. Simulations are divided into user-defined intervals $[t_i, t_{i+1}]$, each corresponding to a Geant4 run. For constant activity, the expected inter-arrival times follow

$$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$

For radioactive decay, activity evolves as

$A(t) = A_0 \exp[-\lambda (t - t_0)],$

and the next emission time is drawn recursively from

$$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$

If $t_{\mathrm{next}}$ exceeds the current interval, the SourceEngine advances to the next run or suspends emission in the gap. For user-defined time-activity curves, $A(t)$ is obtained by linear interpolation between $(t_i, A_i)$ pairs. All primaries carry a global time stamp into Geant4, enabling time-coincidence PET and prompt-$\gamma$ timing studies (Krah et al., 14 Jul 2025).

Part I further describes dynamic parameterization as a unified framework for time-dependent runs in which users provide run intervals $\{(t_i, t_{i+1})\}$ together with per-run parameter lists such as CT images or rotation matrices. This links temporal source behavior with time-varying geometry or acquisition state (Sarrut et al., 14 Jul 2025).

4. Parallel execution and scoring

GATE 10 introduces an overhaul of parallel execution with support for both multithreading via G4MT and multiprocessing via fork or MPI. Physics modules, including actors, digitizers, and scorers, were audited and made thread-safe. ROOT I/O and Python-side data aggregation are organized so that each worker writes its own file and the outputs are merged at the end; multiprocessing is handled either through Python’s multiprocessing or external MPI launchers (Sarrut et al., 14 Jul 2025).

The reported benchmark for a standard PET simulation on a 32-core Intel Xeon/E5 system uses the speedup definition $S(N)=T(1)/T(N)$ and reports a parallelizable fraction of approximately $$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$0, with almost linear scaling up to 32 threads. A late-entry benchmark on a 64-core AMD EPYC system showed comparable behavior with $$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$1 (Sarrut et al., 14 Jul 2025).

$$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$2	$$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$3 [s]	$$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$4
1	1200	1.0
4	310	3.9
8	155	7.7
16	80	15.0
32	42	28.6

The scoring model is actor-based. Actors execute inside the Geant4 event loop and compute quantities including dose, linear energy transfer (LET), and relative biological effectiveness (RBE). LET is described through the stepwise accumulation of energy loss and path length, with

$$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$5

and

$$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$6

In opengate_lib, per-thread arrays record $$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$7 and $$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$8 for each voxel inside SteppingAction, and atomic adds merge the thread-local arrays into the master after the run. If RBE scoring is requested, a phenomenological model such as

$$\Delta t = - \ln(U) / A, \qquad U \sim \mathrm{Uniform}(0,1).$$9

is applied to weight the local dose cell by cell:

$A(t) = A_0 \exp[-\lambda (t - t_0)],$0

Output actors use private thread buffers that are concatenated in RAM, and optionally merged on disk, to return a single final image even for large-thread-count runs (Krah et al., 14 Jul 2025).

5. Variance reduction, source modeling, and algorithmic extensions

Part I enumerates several new or enhanced algorithms in variance reduction, geometry handling, and scoring. The Track-Length Estimator (TLE) in hybrid mode computes voxel dose using

$A(t) = A_0 \exp[-\lambda (t - t_0)],$1

and is reported to provide up to $A(t) = A_0 \exp[-\lambda (t - t_0)],$2 speedup below 1 MeV gamma by switching automatically between standard transport and TLE (Sarrut et al., 14 Jul 2025).

The Free-Flight Hybrid SPECT method weights primary photons by the angular acceptance $A(t) = A_0 \exp[-\lambda (t - t_0)],$3 and splits Compton and Rayleigh components for scatter, with

$A(t) = A_0 \exp[-\lambda (t - t_0)],$4

The reported performance is approximately $A(t) = A_0 \exp[-\lambda (t - t_0)],$5 speedup in low-count scatter regions, while modeling both primary and scattered photons (Sarrut et al., 14 Jul 2025).

For decay-chain simulations, PHID (“Photon from Ion Decay”) uses Bateman equations,

$A(t) = A_0 \exp[-\lambda (t - t_0)],$6

to precompute photon emission rates along decay chains such as $A(t) = A_0 \exp[-\lambda (t - t_0)],$7. The paper reports approximately $A(t) = A_0 \exp[-\lambda (t - t_0)],$8 speedup relative to analog transport together with a $A(t) = A_0 \exp[-\lambda (t - t_0)],$9 gain in detected photons (Sarrut et al., 14 Jul 2025).

AI-coupled source modeling is also explicit. GAN-based sources use a conditional generator $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$0 to replace low-statistic phase-space generation. When combined with angular response functions (ARFs), the reported speedup in PET imaging is approximately $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$1. The related optiGAN method halved optical Monte Carlo time with greater than 92% fidelity (Sarrut et al., 14 Jul 2025).

Part II places these features in a more general extensibility framework. Biasing techniques and AI-based generators can be injected on the fly through callbacks, including user-provided G4WrapperProcess subclasses that implement Russian roulette, splitting, or weight-window logic in a Python–C++ trampoline path. More generally, actors and user processes may intercept SteppingAction and dispatch either to Python or C++ for advanced transport modifications (Krah et al., 14 Jul 2025).

6. Development workflow, platform support, and application domains

The development model of GATE 10 is described as a fully modernized DevOps workflow designed for an open-source project with 80+ global contributors. The project uses a GitHub monorepo containing code, Python bindings, examples, and tests; pull requests require enforced templates covering feature description, test cases, and documentation; and the continuous-integration matrix spans Linux, macOS, and partially Windows, Python 3.9–3.12, and MPI or no-MPI configurations. The test suite includes over 230 automated Monte Carlo tests using Z-score, Wasserstein distance, and image-difference criteria, each running in less than two minutes. The workflow also includes weekly full-matrix runs, a “Monte Carlo-inspired” randomized subset on every commit, and release artifacts published to PyPI and conda-forge (Sarrut et al., 14 Jul 2025).

The extension mechanism is intentionally lightweight: a new actor or source defines a subclass of GateObject and registers via a decorator. The stated contribution workflow is:

fork $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$2 feature branch $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$3 PR $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$4 CI $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$5 code review $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$6 merge $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$7 nightly binary build $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$8 docker/pip release (Sarrut et al., 14 Jul 2025).

Platform requirements are also specified. Supported Python versions are 3.9–3.12; Geant4 must be $$t_{\mathrm{next}} = t^n - \ln(U)/A(t^n), \qquad U \sim U(0,1).$$9; ITK is 5.x through Python itk; ROOT is 6.24.` for list-mode output; PyTorch *$t_{\mathrm{next}}$0 is optional for GAN sources; NumPy, SciPy, and uproot use latest stable versions. Supported operating systems are Ubuntu 20.04/22.04, macOS 11+, and Windows 10/11 with the caveat that on Windows, core features work but ROOT + MT is not yet fully functional. CPU support is x86_64 (AVX2+), with ARM64 planned, and GPU support is NVIDIA (CUDA 11+) for optiGAN and GAN workloads. Installation is described as pip install opengate, with approximately 2 GB of Geant4 physics data downloaded on first run; a developer mode builds Geant4 and ITK from source for extensions (Sarrut et al., 14 Jul 2025).

The reported application domains span PET/SPECT system design, proton/ion therapy, brachytherapy planning, linac phase-space modeling, optical detector R&D, teaching and training, and embedded treatment planning systems and deep-learning–based reconstructions via the library API. Part II further emphasizes direct coupling to external tools such as AI models for source generation or detector response, and repeated sim.run() invocations in the same interpreter through fresh subprocesses to bypass Geant4 singleton constraints while preserving in-memory workflows (Krah et al., 14 Jul 2025, Sarrut et al., 14 Jul 2025).

Taken together, these features define GATE 10 as a Geant4-based Monte Carlo framework whose distinguishing properties are a Python-native interface, a modular C++/Python execution stack, time-aware primary generation, multithreaded and multiprocessing execution, actor-based LET/RBE scoring, explicit support for variance reduction and AI-coupled source models, and a CI-driven development process aimed at sustained academic and industrial use in medical physics.