Wrong CNA value when LAMMPS is run in a loop using next


I was trying to implement the strain-boost Hyprdynamics within LAMMPS. For which I need to compute the local atomic strain. I was accessing the neighbor information the same way it is done in compute_cna. When LAMMPS is run in a loop, it is giving unexpected values. The issue can be reduced to while computing CNA as well using the attached script.

It seems LAMMPS is giving wrong Common Neighbor Analysis(CNA) values when LAMMPS is run recursively using ‘next and jump’ feature and a restart file is written at the same time.
Attached is a minimal input script to reproduce the problem.
If the line “restart 100 restart.*.comp” is commented out in the input script then it will give correct CNA values all the time.

I have compiled LAMMPS from the developed branch. The latest commit hash according to ‘git log’: 993a7cce5465fae94f876c24090c63c07a332e76.

log.lammps (12.7 KB)
script_LAMMPS_Basic.in (1022 Bytes)

Subhendu Chakraborty

Instead of using a global restart command, have you tried using a write_restart command within the loop after the run command?

Hi Axel,

Thanks for your input!
Yes, using write_restart does not create any problem and computes the CNA values as expected.



It seems the issue is not specific to writing the restart file. But if there is no writing activity(dump or restart) in between the run within the loop, it’s giving the wrong neighbor information.
The attached input script will also show the wrong CNA value in the alternate snapshot, although the neighbor list is not updated (“Neighbor list builds = 0”) in between the run as per the log file. But if I change the writing frequency(more frequently than ‘nRun’) either using restart or dump the issue goes away, at least that’s what it seems. E.g., by changing the dump frequency in the attached script from 100 to 10.

If I compare the log files there is a difference in the neighbor statistics. So if I only change the dump frequency from 100 to 10, a “diff” of the log files shows this(check diff.log in the attached files):

< FullNghs:       701556 ave      707004 max      696247 min
> FullNghs:       701470 ave      706843 max      696000 min
< Total # of neighbors = 2806222
< Ave neighs/atom = 175.38888
> Total # of neighbors = 2805878
> Ave neighs/atom = 175.36738

Additional information:
#. The problem still appears whether using a single processor or multiple.
#. Changing the boundary from “ppp” to “sss” to prevent atoms from hopping from one side to other does not help.
#. A dry run without any time integration does not show up the problem.

script_LAMMPS_Basic.in (1.0 KB)
log.lammps (12.9 KB)
diff.log (6.9 KB)

Please report this as a Bug report issue on GitHub: Issues · lammps/lammps · GitHub

Submitted a bug report at LAMMPS Github. #4231