KAHIBARO
40.3. Simulation Speed
Table of Contents
Event throughput
Simulation speed in GATE is usually described by event throughput, the number of events processed per unit time. For practical work you typically think in events per second or events per hour. When you plan or optimize a simulation, you always want an estimate of how fast your set up runs so you can decide how many events or how long a run is realistic.
In a Monte Carlo simulation an event usually corresponds to one primary particle history. That primary can generate many secondary particles and a lot of tracking work. The more work per event, the lower the event throughput. For a given computer, event throughput is mainly controlled by your physics list and transport parameters, your geometry complexity, and how much information you record through actors and digitizers.
You can measure event throughput directly from the terminal output or from the simulation statistics actor. A simple way is to divide the total number of processed events by the CPU time, for example
$$
R = \frac{N_{\text{events}}}{t_{\text{CPU}}}
$$
where $R$ is the event rate in events per second, $N_{\text{events}}$ is the number of events, and $t_{\text{CPU}}$ is the CPU time in seconds reported by GATE or Geant4.
Important rule: Always measure event throughput for a small test run of your actual configuration before launching very long simulations. Use this measured rate to estimate the required wall time and adapt the number of events, threads, or batch jobs.
Event throughput scales with the number of threads in a multithreaded simulation, but not perfectly. Ideally doubling threads would double $R$, but in practice there is overhead from thread management, memory access, and writing output. For medical physics problems, you often see good scaling up to the number of physical cores, then diminishing returns or even slowdowns if you add more threads than cores.
Physics configuration influences throughput strongly. More detailed physics models, lower production cuts, and longer particle ranges all increase the number of steps per event, which reduces $R$. For imaging studies where you focus on detector response, you might accept coarser transport in less important regions to keep throughput acceptable, while for high precision dosimetry you accept lower throughput.
The amount of output you record can also dominate performance. Writing many large ROOT trees, detailed phase space files, or high resolution dose grids will reduce throughput through I/O overhead and memory usage. For performance, write only the information you really need, and avoid very fine binning unless it is essential.
When you tune event throughput, you usually follow an iterative process. First, set up a realistic but small configuration, measure $R$, and then change one aspect at a time: number of threads, dose grid resolution, actor list, or simplified geometry. After each change, measure again. This lets you see clearly which part of the configuration is the main bottleneck.
Complex geometries
Complex geometries can slow simulations significantly compared to simple test setups. Complexity here means many volumes, many levels of nesting, repeated structures, and voxelized phantoms. Every step that a particle takes requires navigation through this geometry, and more detailed geometry means more navigation work per step.
Typical medical physics simulations often include repeated detector arrays, PET rings, gamma camera heads, and CT or patient geometries made from thousands or millions of voxels. The geometry system must determine which volume a track is currently in, where the next boundary is, and what material to use. In complex set ups this navigation can become one of the dominant costs per event and can reduce event throughput even if the physics list stays the same.
You can usually see the effect of geometry complexity by comparing a simple water box simulation to a full scanner or patient geometry with the same source and physics. The number of events processed per second will often drop by an order of magnitude once you introduce large voxelized images or many small detector pieces.
There are several strategies to control the performance impact of complex geometries without changing the physics goals. One common approach is to use repeated volumes for regular detector structures, for example crystal arrays, instead of creating each volume individually. Repetition lets the geometry engine optimize navigation in these regions, which improves performance. For objects that are not important to your scoring, you can simplify shapes or merge small details into larger approximating volumes.
Voxelized geometries, for example patient CT phantoms, require particular care. Very fine spatial resolution produces many voxels, and each voxel boundary is a potential navigation step. If performance is too low, you can often coarsen the voxel grid for regions where you do not need very fine dose or interaction detail. Material mapping from CT values can also be simplified by grouping tissues into a small set of representative materials instead of many closely spaced variants.
Visualization is useful to understand where geometry complexity might be excessive. By inspecting your model you can identify volumes that add detail but not useful information for your study. Removing or simplifying such parts usually leads to a noticeable gain in event throughput.
Important rule: For complex geometries, always balance realism against performance. Preserve high detail only in regions that affect your key results, and simplify or approximate less critical parts of the geometry to keep simulation speed manageable.
When working with complex geometries on limited hardware, it is often necessary to combine several techniques: moderate simplification of geometry, careful choice of physics models and cuts, fewer high resolution scorers, and appropriate multithreading. Together, these choices help maintain a reasonable event throughput while still meeting the scientific goals of your GATE simulations.
Views: 10