5
$\begingroup$

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

enter image description here

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.

$\endgroup$

2 Answers 2

4
$\begingroup$

I want to share my experience in this topic.

In some certain scenarios, the total energy is highly related to the neighbour list construction.

If the neighbour list is updated infrequently, not only the interaction forces are wrong, but total energy is no longer conserved (by conservation I mean small fluctuations around some mean value). Suppose a particle appears below the cutoff distance but is not registered in the neighbour list (somehow penetrated the "skin" without being recorded), then the neighbour list is updated. After that, the pair interaction energy appears in total energy out of nowhere. This process results in significant contamination of the total energy over time.

This effect was noticeable when I was considering a non-equilibrium system, where some macroscopic parameter was changing over time. However, energy was conserved in the case of an equilibrium system, and my guess is that the above-mentioned process can contribute to total energy both positively and negatively; in the case of an equilibrium system, these contributions compensate each other, while in the out-of-equilibrium scenario, they might be biased, resulting noticeable non-conservation.

So, my approach is to use a large "skin" and sufficiently small rebuild interval with the "check yes" option.

$\endgroup$
1
  • 1
    $\begingroup$ +1 and welcome to our new community! Thanks very much for your contribution and we hope to see much more of you in the future!!! $\endgroup$ Sep 22 at 20:36
3
$\begingroup$

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

$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .