Clarification on setting different random seeds for parallel running

Running and Runtime Errors
1

Dear FLUKA experts and users,

First of all, I would like to thank everyone who contributes to this forum by providing answers, explanations, and examples. The discussions here have helped me resolve many issues and misunderstandings that I would likely not have been able to solve on my own.

I have a question regarding the execution of FLUKA jobs in parallel on a computing cluster (a Slurm cluster in my case). Although I have read several related topics, there are still a few points that I would like to clarify.

  1. I use a bash script that takes a template input file, for example model.inp , and alters the what(2) parameter of the RANDOMIZe card using sed . The template’s value of 1 is replaced by an integer i , where i = 1, ..., n_runs. The modified input is then saved as a new file named model_i.inp. As an example, when running on 100 CPU cores, the script generates the files with names: model_1.inp , model_2.inp , …, model_100.inp and corresponding RANDOMIZe what(2) values: 1 , 2 , …, 100 .
    The what(1) parameter is left blank, so FLUKA uses its default value of 1 .
    Is this a correct approach?

  2. To submit the jobs I use

srun /<path_to_fluka>/bin/rfluka -M n_cycles model_i.inp

command.

My understanding is that a run based on model_i.inp is repeated n_cycles times, with each cycle continuing from a different state of the random number generator (?)

I am not very familiar with the implementation details of random number generation in FLUKA, but I noticed that FLUKA (through its built-in RM64 generator, if I understand correctly) creates files such as ranmodel_ixxx . These files contain a header and a sequence of alphanumeric values. Interestingly, the first value in the header (for example 85020AD ) appears to match the first value reported in the NEXT SEEDS: line of the corresponding .err file.

For example:

85020AD       4       1    3039B66B065F
      D      2E1CD082203FA03501
964CE6DE3FD864BF6EE241783FD35FF9CB4F66AB3FE3FCD ...

and

NEXT SEEDS: 85020AD       4       0       0       0       0       1    3039       0       0

Could someone explain what exactly is happening at this stage of the calculation? In particular, how is the seed specified in the RANDOMIZe card related to the values shown in the ranmodel_ixxx files and the NEXT SEEDS: entries reported in the .err file?

  1. Finally, I would like to confirm whether the procedure described above guarantees statistical independence among all cycles and all submitted jobs (All the sed action done to alter the random seed value in the RANDOMIZe card take place inside a loop scope. The jobs submitting process is also enclosed inside another bash loop body).

Cheers,
Ihor

FLUKA: 4-5.1
Operating system: Ubuntu 24.04 LTS (slurm cluster)

3

Dear Ihor Melnyk,

First, let me assure you that your approach to simulate independent simulations is correct. It is enough to choose different values for WHAT(2) in the randomiz card to obtain statistically independent histories.

The ran* file is generated by the random number generator and is regularly updated by FLUKA. At the end of one cycle, the latest ran* file is basically the state of the random number generator at the end of the simulation. If more than one cycle is requested (M>1 with rfluka), the next cycle reads the ran* file as it was left by the previous cycle to initiate the random number generator. If the file is absent or corrupted for some reason (which should not happen), the next cycle uses only the seed (WHAT(2)) and the next cycle will be the same as the first.

In other words, FLUKA checks for the presence of the latest ran* file, reads it if it exists, and if not, it initiates the random number generator based solely on the seed in WHAT(2).

The state of the random number generator is indeed also reported in the err file, so it is normal that you see some values in both .err and ran files which coincide. Provided you chose different initial seed (WHAT(2)) in the inputs of your parallel jobs, the values reported by FLUKA for the different jobs should be different. The exact meaning of all these values is unfortunately not very well documented

To me it’s seems that your approach is correct. If you want to check whether your different jobs are indeed indepedent histories, you can merge them and check the statistical errors. If this error is not zero, your simulations are statistically independent.

4

Dear Benoit Lefebvre,

Thanks for your explanation!
Now it’s clear how to ensure statistical independence of the different cycles of different parallel runs. I checked the merged output files, specifically those belonging to the different cycles of the same run, as you suggested and made sure that they are different (errors are not zero).

Cheers,
Ihor