hmc_tm: add real reproducible random numbers mode #293
Conversation
kostrzewa
force-pushed
the
save_ranlux_state
branch
5 times, most recently
from
ce46552
to
ca6f667
Compare
kostrzewa
changed the title
|
@kostrzewa why using a file. We could reset before each trajectory the RNG state to something depending only on the trajectory number. This would automatically lead to reproducible random numbers if chosen in the input file? |
|
That's also acceptable I guess, except if you want to do this with two different initial seeds. I guess one could of course just use seed^trajcounter -> start_ranlux(seed,level) before each trajectory, the overhead should be minimal and ranlux is probably robust enough that this kind of constant restart should not pose a problem. Is there any chance of seed^trajcounter being non-unique? (i.e. giving the same result for the same seed but two different values of trajcounter) |
I guess this could happen if one of them is |
|
yes, it might happen that we have for a trajectory the same random numbers. this is not a problem, it only becomes one when it happens regular and often. Can't we make it as unique as possible? |
Are you sure that can happen? I don't really see how. As long as seed and trajcounter are the same data type the XOR should not cause the same seed to be used ever (in a given run that is and as long as you do fewer than 2^31 trajectories). So I think that as long as one disables the computation of the local seed in the "truly reproducible" case, your idea should achieve the required effect. I sort of liked the solution with the file because it allows "exporting" the RNG state to a different run even without having matching trajectory numbers. |
|
The only "problem" I have with the file version is that you loose meta-data and files might get lost, but it could be added optional? My proposal is a bit more fool save... |
|
Okay, I will implement both, it should not be difficult to do. |
kostrzewa
force-pushed
the
save_ranlux_state
branch
from
ca6f667
to
0bc8fb5
Compare
… RNG state consistent across executions of different numbers of trajectories (say you have a serial run doing 1000 trajectories at a time in 10 goes and a parallel run doing 10000 trajectories in one run, with this mode, the two runs will still have exactly the same random numbers because the RNG state is saved to file between executions of hmc_tm)
kostrzewa
force-pushed
the
save_ranlux_state
branch
from
0bc8fb5
to
9249e2d
Compare
|
Is this in principle ready to be merged? |
|
Your proposal is still missing, other than that, I've tested this at the time. |
this will keep the RNG state consistent across executions of different numbers of trajectories (say you have a serial run doing 1000 trajectories at a time in 10 goes and a parallel run doing 10000 trajectories in one run, with this mode, the two runs will still have exactly the same random numbers because the RNG state is saved to file between executions of hmc_tm)
This works only when using reproducible_random_numbers and when the random numbers are requested only through functions supporting this mode.