inconsistency in pe variable from python

Hi - I’m using the python lammps interface, and I’m seeing some weird behavior.

I set up a configuration, then call lmp.command(“run 16”) to do a bit of MD. I want the final energy, so I then do
    lmp.extract_variable(‘pe’, None, 0)
However, if I then immediately do lmp.command("run 0”), and extract_variable again, I (occasionally) get a different energy.

A bit of testing with extract_compute(‘thermo_pe’, 0, 0) appears to behave the same way.

1. Am I correct in believing that that this should never happen?
2. This is part of a large and complex run - this happens (deterministically) only after doing this sort of thing (various combinations of “run 16”, “run 0”, and lots of other python stuff) thousands of times. Any ideas how to go about debugging it further?

                Noam

Hi - I’m using the python lammps interface, and I’m seeing some weird
behavior.

I set up a configuration, then call lmp.command(“run 16”) to do a bit of
MD. I want the final energy, so I then do
    lmp.extract_variable(‘pe’, None, 0)
However, if I then immediately do lmp.command("run 0”), and
extract_variable again, I (occasionally) get a different energy.

​*how different*? do you also get this with lmp.command("run 0 pre no")?​

A bit of testing with extract_compute(‘thermo_pe’, 0, 0) appears to behave
the same way.

1. Am I correct in believing that that this should never happen?

​it can happen. the question is how large the difference is and what kind
of system you have.

2. This is part of a large and complex run - this happens
(deterministically) only after doing this sort of thing (various
combinations of “run 16”, “run 0”, and lots of other python stuff)
thousands of times. Any ideas how to go about debugging it further?

​try running with enforced neighbor list rebuilds in every step, i.e.:

neigh_modify delay 0 every 1 check no​

​axel.​

Significantly different. One example is 0.1 eV out of -1.4 eV or so, for a system that’s basically gas, with just a few atoms interacting. Enough that it’s messing up my algorithm.

Adding “pre no” doesn’t change anything.

Interesting. That does fix it. I guess I have to do some benchmarking to see how that affects my overall runtime. I looked over the neigh_modify documentation, and I think I understand what your suggestion is doing. Do you have any suggestions or heuristics as to when “check no” vs. “check yes” are optimal?

thanks,
Noam

Hi - I’m using the python lammps interface, and I’m seeing some weird
behavior.

I set up a configuration, then call lmp.command(“run 16”) to do a bit of
MD. I want the final energy, so I then do
    lmp.extract_variable(‘pe’, None, 0)
However, if I then immediately do lmp.command("run 0”), and
extract_variable again, I (occasionally) get a different energy.

​*how different*?

Significantly different. One example is 0.1 eV out of -1.4 eV or so, for a
system that’s basically gas, with just a few atoms interacting.

​ok. that is beyond significant. that is what i would call massive.​

Enough that it’s messing up my algorithm.

do you also get this with lmp.command("run 0 pre no")?​

Adding “pre no” doesn’t change anything.

​ok. that eliminates several possible sources of problems.​

A bit of testing with extract_compute(‘thermo_pe’, 0, 0) appears to
behave the same way.

1. Am I correct in believing that that this should never happen?

​it can happen. the question is how large the difference is and what kind
of system you have.

2. This is part of a large and complex run - this happens
(deterministically) only after doing this sort of thing (various
combinations of “run 16”, “run 0”, and lots of other python stuff)
thousands of times. Any ideas how to go about debugging it further?

​try running with enforced neighbor list rebuilds in every step, i.e.:

neigh_modify delay 0 every 1 check no​

Interesting. That does fix it. I guess I have to do some benchmarking to
see how that affects my overall runtime. I looked over the neigh_modify
documentation, and I think I understand what your suggestion is doing. Do
you have any suggestions or heuristics as to when “check no” vs. “check
yes” are optimal?

​have you checked your output with check yes? does it mention "dangerous
builds"?​

the "check yes" option makes assumptions that are typical for liquid
conditions. if you have a small number of atoms, you may want to try out
the "nsq" neighbor list construction method. you can also play a little
with the choice of neighbor list skin parameter. in liquids, you don't want
to get the "skin" too large, as the number of pairs grows O(N**3) with the
neighbor list cutoff. but for low densities, that is less of a concern. the
"bin" method has more overhead, but is linear scaling in contrast to the
low overhead O(N**2) of the "nsq" method.
you can try and see, if with a larger skin and check yes, you get better
performance, or a smaller skin and check no.

​axel.​

Hmm. I normally don’t keep output, but I can turn on logging and check.

I get the problems in the gas regime, but eventually I get into the condensed phase, and I’m actually more worried about efficiency in that regime (as long as the initial gas phase stuff actually works correctly, even if it’s a bit less efficient). I’ll check your suggestions.

thanks again,
Noam