KAHIBARO
39.2. Random Seeds
Table of Contents
Reproducing simulations
When you run a GATE simulation, many decisions are made using random numbers. For example, each interaction position, scattering angle, and sampled energy comes from a pseudo random number generator. If you do not control this generator, every run will produce slightly different results, which is good for realism but bad for debugging and verification.
A random seed is the number that initializes the random number generator. If you set the same seed, GATE will repeat the same sequence of pseudo random numbers. That means, for a fixed simulation configuration, you can reproduce the same tracks, hits, dose values, and output files bit by bit.
A fixed random seed plus an unchanged simulation configuration and software environment leads to a bitwise reproducible simulation.
Changing the seed alone gives a statistically equivalent but different realization of the same simulation.
In practice, you usually do two different things with seeds. First, during development and debugging, you set a known, fixed seed, so that a problem is reproducible. If your simulation crashes at event 1234, you can re run it and see the same event 1234 again. Second, during production runs, you deliberately change the seeds for independent jobs, so that each run explores a different random sequence and you can combine results safely.
In OpenGATE, seeding is typically done through configuration of the random engine. A common pattern in Python is to set a seed as part of the simulation setup, before starting the run. For instance, you might read a seed from a configuration file or command line argument, assign it to the simulation random manager, and then record this value in your output folder. This way, someone can later look at the output metadata, read the exact seed, and reproduce that specific run.
It is important to understand the limits of reproducibility. If you change the physics list, geometry, materials, number of threads, or even the version of Geant4, you cannot expect bitwise identical results, even with the same seed. In that case, reproducibility means that the new results remain statistically compatible with the old ones within Monte Carlo uncertainty, not that every event is identical. For strict reproducibility tests, keep the entire software stack constant, including compiler and libraries, whenever possible.
Finally, seeds play a key role in large scale simulations and parameter studies. On HPC systems, you may submit many jobs that share the same geometry and sources but use different seeds. Each job then generates an independent sample, and you combine the outputs to reduce statistical uncertainty. In that context, you must ensure that no two jobs accidentally share the same seed. A simple approach is to derive the seed from the job index. Another is to keep a registry of used seeds along with the corresponding run configurations in your project documentation, so that you can always trace back how a given dataset was produced.
Views: 9