When I run long enough with fix temp/csvr, I tend to get the error message:
ERROR on proc 0: Non-numeric atom coords - simulation unstable (…/domain.cpp:510)
When I change the random number, the timestep at which this error occurs changes.
I did some debugging, and I believe the bug is in the FixTempCSVR::gamdev function in fix_temp_csvr.cpp, lines 51-52 (and perhaps also later on in the same function). If random->uniform() gives 0, then x becomes equal to 0, and log(0) gives inf.
I’m guessing this is due to a float precision error. Doing something like
double random=random->uniform();
while (random==0)
random=randon->uniform();
x *= random
fixes things for me, though perhaps it’s better to fix this directly in random_mars.cpp.
I’m no expert at random number generation, so I can’t guarantee that doing this doesn’t make the resulting distribution improper.
Example below, with data file attached.
system.data (340 Bytes)
When I run long enough with fix temp/csvr, I tend to get the error message:
ERROR on proc 0: Non-numeric atom coords - simulation unstable
(../domain.cpp:510)
When I change the random number, the timestep at which this error occurs
changes.
I did some debugging, and I believe the bug is in the FixTempCSVR::gamdev
function in fix_temp_csvr.cpp, lines 51-52 (and perhaps also later on in the
same function). If random->uniform() gives 0, then x becomes equal to 0, and
log(0) gives inf.
would you mind reporting this as an issue at:
https://github.com/lammps/lammps/issues
I'm guessing this is due to a float precision error. Doing something like
double random=random->uniform();
while (random==0)
random=randon->uniform();
x *= random
fixes things for me, though perhaps it's better to fix this directly in
random_mars.cpp.
no, that would be a very bad idea.
I'm no expert at random number generation, so I can't guarantee that doing
this doesn't make the resulting distribution improper.
exactly. 0 is a valid result from a RanMars::uniform()
axel.
When I run long enough with fix temp/csvr, I tend to get the error message:
ERROR on proc 0: Non-numeric atom coords - simulation unstable
(../domain.cpp:510)
When I change the random number, the timestep at which this error occurs
changes.
I did some debugging, and I believe the bug is in the FixTempCSVR::gamdev
function in fix_temp_csvr.cpp, lines 51-52 (and perhaps also later on in the
same function). If random->uniform() gives 0, then x becomes equal to 0, and
log(0) gives inf.
would you mind reporting this as an issue at:
https://github.com/lammps/lammps/issues
I'm guessing this is due to a float precision error. Doing something like
double random=random->uniform();
while (random==0)
random=randon->uniform();
x *= random
fixes things for me, though perhaps it's better to fix this directly in
random_mars.cpp.
no, that would be a very bad idea.
in this case, the best way would be to bypass the -log() completely
for small and denomalized x and just output a suitably large number,
that is larger than the largest possible number that could be produced
from -log(x).
i've implemented this in LAMMPS-ICMS and will forward it to steve for
inclusion into upstream now.
axel.