About neigh_modify and dangerous builds in LAMMPS

Question

I am doing a simulation of a 3D LJ system in LAMMPS, where I am heating an already equilibrated configuration at $T^* = 0.3$ to $T^* = 0.4$ for $1000000$ steps then equilibrating the same at $T^* = 0.4$ for $3000000$ steps. My system consists of 14713 atoms, the lj/cut parameters I am using are $\epsilon = 1$, $\sigma = 1$, and cutoff $4.0$. Timestep size is default lj timestep size $0.005 \tau$, and the neighbor skin distance is 0.3 bin.

Now I have a few questions regarding the neigh_modify command. I have done 4 simulations using the conditions specified above but changing the neigh_modify command arguments as below -

1. neigh_modify every 1 delay 0 check yes
2. neigh_modify every 1 delay 0 check no
3. neigh_modify every 20 delay 0 check yes
4. neigh_modify every 20 delay 0 check no

I have plotted the Total Energy vs Timestep for these 4 simulations and compared them, and the plots are identical. My 1st question is if regardless of how we build the neighbor list, the results are the same, what is the need for this command? or am I making comparisons with the wrong properties and I need to validate with some other properties?

Also, in the case of neigh_modify every 20 delay 0 check yes I get $50000$ Dangerous builds (which is equal to my Neighbor list builds). What is the significance of this, if the energy of the system is statistically the same no matter what? P.S. - the 4 simulations are also identical throughout the whole simulation, visually.

And finally, when I use neigh_modify every 1 delay 0 check no the simulation runs almost twice as slow compared to all other cases. ($915.333$ timesteps/s compared to $\approx 2201.750$ timesteps/s on average for other cases). Why this is happening?

Thank you for your help.

Answer 1

I am answering this question based on the reply I was receiving from Axel Kohlmeyer in the LAMMPS community discussion forum.

My 1st question is if regardless of how we build the neighbor list, the results are the same, what is the need for this command? or am I making comparisons with wrong properties and I need to validate with some other properties?

The results are not going to be the “same”. The longer the delay between neighbor list rebuilds, the larger the chance that you are missing the contribution of interacting pairs of atoms within the cutoff because they have moved inside the cutoff range since the last neighbor list rebuild. Since you are using a rather large cutoff the differences (in potential energy) due to the missed contributions will be very small. A setting for “delay 20” is at the limit of what is an acceptable choice for your kind of system. The total energy is not a good parameter since the differences due to the missed interactions is small relative to the total energy.

Regardless of whether the neighborlist rebuilds are done sufficiently frequent or not, if you build neighbor lists on different timesteps, you will change the order in which forces are summed up, which will lead to small numerical differences on the forces (due to limitations of floating point math) and thus to exponentially diverging trajectories. They will still be statistically equivalent.

What is the significance of this, if the energy of the system statistically the same no matter what?

Dangerous builds are a consequence of the neighbor list skin and a check that LAMMPS is doing when a neigh_modify check yes setting is used. This is based on a heuristic: if any atom has moved more than half the neighbor list skin distance since the last neighbor list build, the current update is considered “dangerous”, i.e. there is a risk, that some interacting pair has been missed in the force computation of the time step(s) before the one where the neighbor list build happens. This heuristic of a half the skin distance is very conservative, so you can have dangerous builds and still correct neighbor lists. However, if you have no dangerous builds, it is certain that all neighbor lists were correct.

Why this is happening?

Yes, that is because the time consuming rebuild of the neighbor list is deferred until the neighbor list check heuristic is reached, and the check for it is fast. Please have a look at the timing summary and the number of neighbor list rebuilds. Your second case enforces a neighbor list rebuild in every step and that is not needed at all. About every 10 steps should be a safe choice and every 20 is probably still acceptable, even if you may miss a very distant pair occasionally since your cutoff is so large.

Link to original answer - About neigh_modify command and dangerous builds