In attempting to run an ensemble of simulations, I set the ensemble_run = .true. and lperturb_t = .true. options. The log file reports Appling perturbation to input dataset: T with value 0.10%, indicating that the ensemble code is indeed active. Despite this, simulations are bit-for-bit identical.
Diagnostics indicate that issue is related to the code that seeds the random number generator in Share/mod_ensemble.F90. In randify3D, the cputime variable receives a unique value for each run (e.g., 0.452986 in one case and 0.832958), but the seed = int(cputime) + 37*[(i-1,i=1,nseed)] line truncates it to the same integer value each run. Since each run is given an identical random number seed, the results are identical.
The original implementation used the system_clock function, which returns an integer value indicative of the system time: it should be unique for each run and would not suffer from a truncation issue. I assume the system_clock function was introduced in ef58d7d in the interest of portability across compilers.
Note: This issue has been present since 2012 (see commit ef58d7d) and may affect existing ensemble simulations. For systems with large runtime variability (variability > 1 second), the ensemble system may have worked as intended.
I'll submit a pull-request momentarily that modifies the code to avoid the potential for truncation of cpu_time to result in identical ensemble members. It multiplies cputime by a relatively large number before converting to an integer.
In attempting to run an ensemble of simulations, I set the
ensemble_run = .true.andlperturb_t = .true.options. The log file reportsAppling perturbation to input dataset: T with value 0.10%, indicating that the ensemble code is indeed active. Despite this, simulations are bit-for-bit identical.Diagnostics indicate that issue is related to the code that seeds the random number generator in
Share/mod_ensemble.F90. Inrandify3D, thecputimevariable receives a unique value for each run (e.g., 0.452986 in one case and 0.832958), but theseed = int(cputime) + 37*[(i-1,i=1,nseed)]line truncates it to the same integer value each run. Since each run is given an identical random number seed, the results are identical.The original implementation used the
system_clockfunction, which returns an integer value indicative of the system time: it should be unique for each run and would not suffer from a truncation issue. I assume thesystem_clockfunction was introduced in ef58d7d in the interest of portability across compilers.Note: This issue has been present since 2012 (see commit ef58d7d) and may affect existing ensemble simulations. For systems with large runtime variability (variability > 1 second), the ensemble system may have worked as intended.
I'll submit a pull-request momentarily that modifies the code to avoid the potential for truncation of
cpu_timeto result in identical ensemble members. It multipliescputimeby a relatively large number before converting to an integer.