KAHIBARO
40.1. Multithreaded Simulation
Table of Contents
Worker threads
GATE uses the multithreading system provided by Geant4. Instead of running one event after another on a single CPU core, the simulation can create several worker threads. Each worker thread transports its own set of events, in parallel with the others.
In a multithreaded GATE run, there is exactly one master thread and one or more worker threads. The master thread is responsible for tasks such as reading your Python configuration, building the geometry and physics, and preparing actors and digitizers. Once this setup is finished, the master thread starts the worker threads.
Each worker thread receives a portion of the total number of events. For example, if you request $N_\text{events} = 10^7$ and you use 10 threads, each thread will typically simulate about $10^6$ events. The exact distribution can vary slightly, but for most purposes you can think of the total events as being divided evenly among the workers.
Worker threads have their own copies of most Geant4 and GATE objects that are involved in event processing. This includes random number generators, particle stacks, and thread-local buffers used by actors and digitizers. This design avoids race conditions because two threads never try to modify the same event-level data simultaneously.
From the user perspective, you usually control the number of worker threads through a configuration parameter in your Python script or via an environment variable. On a typical multi-core CPU, it is common to choose a number of threads equal to the number of physical cores or slightly less, so that all cores are used effectively without oversubscription.
Some important implications of worker threads are related to randomness and reproducibility. Each thread uses its own random engine that starts from a seed derived from the global seed. As a result, if you change the number of threads but keep the same global random seed, you do not obtain exactly the same sequence of random events. The total physics results should remain statistically consistent, but the detailed event order and hit patterns will differ. If you need strict reproducibility, you must keep both the random seed and the number of worker threads fixed.
Multithreading also affects how actors and digitizers accumulate data. During event processing, each worker thread often fills its own local data structures. At the end of the run, these per-thread results are merged into a single output, such as one ROOT file or one dose image. This merge step is handled internally by GATE and Geant4, so you normally do not have to manage it manually, but you should be aware that your final result is the sum of many thread-local contributions.
Worker threads simulate different events in parallel, each with its own random sequence and local data. Changing the number of threads changes how events are distributed across threads and can slightly change detailed results, even with the same random seed.
Parallel execution
Parallel execution in GATE is event-based. Each event is an independent history of particles transported through your geometry using the configured physics processes. Because events are statistically independent, they can be simulated in any order. Multithreading uses this property to process many events at the same time.
When you enable parallel execution, the master thread creates several worker threads and assigns event ranges to them. Each worker then runs the complete simulation chain for its events. Geometry, materials, physics lists, sources, actors, and digitizers are all applied as usual, but for a subset of the total events on each thread.
The main benefit of parallel execution is a significant reduction in wall-clock time for large simulations. If your simulation is CPU-bound and scales well, doubling the number of threads can nearly halve the runtime. The actual speedup depends on factors such as the complexity of your geometry, how much time is spent on I/O, and the balance between computation and memory access.
Parallel execution does not change the physics models or the meaning of your configuration. A dose actor, for example, still accumulates deposited energy per voxel. The difference is that contributions to each voxel come from many threads instead of one. At the end of the run, all per-thread voxel contributions are reduced into a single dose image.
Some parts of a simulation are not fully parallel, which limits the maximum possible speedup. Building geometry and materials, initializing physics, and writing certain outputs involve global operations that are performed by the master thread. This is an example of Amdahl’s law, which states that the speedup is limited by the serial fraction of the code. For typical GATE simulations, most of the runtime is in event processing, which is parallel, so multithreading still provides a substantial benefit.
To take full advantage of parallel execution, you should avoid unnecessary synchronization points and excessive I/O inside the event loop. Writing a text line for every event or storing very large per-event data can reduce scaling, because the threads spend more time waiting on shared resources such as the file system. Instead, rely on actors and digitizers that accumulate statistics in memory during the run and only write to disk at the end of the simulation or at well-defined checkpoints.
From a practical viewpoint, you can test parallel execution by running the same simulation with one thread and with several threads, then comparing key results such as total deposited energy, average dose in selected regions, or total counts in detectors. The values will not match event by event, but within statistical uncertainty they should agree. If you notice systematic differences larger than expected statistical fluctuations, that may indicate a configuration or analysis problem unrelated to multithreading itself.
Parallel execution in GATE simulates different events on different threads. Physics results should be statistically the same as a single-thread run, but exact event sequences and detailed outputs differ. Always compare aggregated quantities within their Monte Carlo uncertainties when checking multithreaded behavior.
Views: 11