About neigh_modify command and dangerous builds

Hello, Everyone.
I am doing a simulation of a 3D LJ system in NVT, 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 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 statistically the same no matter what?
P.S. - they 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,
Bose

Hi,

It is happening because you are re-building the neighbor lists more frequently, and building neighbor lists is one of the most computationally expensive action in a MD simulation.

The meaning of dangerous build has been described here many times, see for instance:

Best,
Simon

It is happening because you are re-building the neighbor lists more frequently, and building neighbor lists is one of the most computationally expensive action in a MD simulation.

I am re-building the neighbor lists more frequently in both neigh_modify every 1 delay 0 check yes and neigh_modify every 1 delay 0 check no. But for the 1st case, simulation is twice as fast compared to the 2nd case.

The meaning of dangerous build has been described here many times

Yes, but since in my case, the total energy of my system is the same when there is a 0 dangerous build and when there are 50000 dangerous builds. How is the presence of a dangerous build is affecting my simulation? If it is not affecting energetically, then where?

Regards,
Bose

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.

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.

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.

1 Like