KAHIBARO
21.3. Running Independent Simulations
Table of Contents
Different seeds
When you run the same Geant4 application many times, each run should represent a different possible outcome of the same physical experiment. To achieve this, you must change the random seed, because the random engine in Geant4 generates a deterministic sequence of numbers from a given seed. If two runs start from the same seed and follow the same code path, they will be bit‑for‑bit identical.
The random seed is typically set once at the beginning of a run, before you start /run/beamOn. In C++ you can set seeds through the CLHEP random engine that Geant4 uses. A simple pattern is to choose seeds from an external source, for example the system time, a run index, or a combination of both. You can also expose this as a macro parameter so you do not need to recompile when changing seeds.
A robust practice is to control seeds explicitly, rather than relying on whatever default Geant4 chooses. For example, you might compute a pair of 32‑bit integers from an integer run ID. This prevents accidental reuse of the same seed, especially in batch scripts or on clusters. It is also important to log the seed for every run you produce. Store it in a text file, in your output file header, or in the run name. That way, if you need to re‑run a particular sample with the same random history, you can reproduce it.
In multithreaded jobs, there is one master engine and multiple worker engines. Geant4 handles per‑thread seeding internally, but you still control the initial master seed. If you submit several multithreaded jobs to a cluster, each job should start from a different master seed so that the threads in different jobs do not repeat each other.
Use a different explicit seed for every independent run you want to combine statistically. Record the seed you used, so you can reproduce or debug specific samples later.
Statistical independence
Independent simulations are useful only if their statistical fluctuations are genuinely uncorrelated. This is what is meant by statistical independence of runs. In practice, you want each run to sample a different part of the random sequence, without overlap, and without hidden correlations that might bias averages or uncertainties.
Using different seeds for each run is the first requirement, but not the only consideration. Some choices can accidentally reduce independence. For example, if you derive seeds from a simple formula that cycles after a small number of runs, or if two jobs inadvertently reuse the same seed, then those runs are not independent. On a batch system, submitting the same macro file many times without changing the seed is a common source of such hidden correlations.
When you plan to merge results from many runs, treat each run as one statistically independent sample. You can then average quantities like mean energy deposition, transmission, or efficiency across runs. The statistical uncertainty of the combined result will scale roughly as $1/\sqrt{N_\text{events}}$ where $N_\text{events}$ is the total number of events from all independent runs. This scaling is only valid if the random numbers that drive each event are uncorrelated beyond what the random engine itself guarantees.
Another aspect of independence is the separation of test runs from production runs. A short test that you use to tune geometry or cuts should not be mixed into the final statistics unless you are sure that it is produced under the same physics settings and with an appropriate independent seed strategy. It is better to clearly separate test outputs from production outputs and document the number of events and seeds for each sample.
When you run on a cluster, tools such as job IDs or array indices can help you generate nonoverlapping seeds. If you use a job array index as part of your seeding scheme, each array element will start from a different part of the random sequence. Combined with careful logging, this gives you a collection of truly independent simulations that you can safely merge.
Only combine results from runs that:
- Use different seeds, and
- Were generated with identical physics and configuration.
Under these conditions, you can treat runs as statistically independent and apply standard error estimates based on $1/\sqrt{N}$.
Views: 7