I am running simulations with the MPI version of LAMMPS (as seen in my log file, dated “LAMMPS (7 Jan 2022)”) on a system containing approximately 2.9 million atoms. In the diagnostic output related to neighbor list construction, I have observed some unexpected entries that I would like to clarify.
Specifically, the log file reports:
• Total # of neighbors = 0
• Ave neighs/atom = 0
• Neighbor list builds = 425
• Dangerous builds = 1
Despite these reports, the simulation dynamics run smoothly without warnings, and computed properties (such as g(r)) show no discrepancies between MPI and serial runs.
Could you please help me understand the following:
Do non-zero counts of dangerous builds indicate any potential issues with simulation accuracy or stability?
Should I consider any adjustments to my simulation in for example neighbor and neigh_modify commands to stop these dangerous builds, or can they be safely ignored?
“Dangerous Builds” means “at least one atom has moved half the skin distance or more” since the last time the neighborlist was rebuilt. Since you are already using conservative settings for the neighbor list build (every 1 steps, delay 0 steps, check yes), your timestep may be too large and you could be missing interactions between atoms. Note that the check is fairly conservative and doesn’t always mean you have a problem, but you could in some cases, i.e. it is “dangerous”.
Yes. It means that you are running a risk that not all interactions close to the cutoff are computed correctly because the wrong atoms are in the neighbor list (and are thus ignored) and atoms that should be in the neighbor list are missing.
You need to reduce your time step.
That doesn’t mean anything. Even simulations with very bad settings can run without warnings.
If those are all run with too large a timestep, then they can be all “wrong” in the same way.
Simulations can run without crashing while still having wrong integration – an aggressive thermostat can smooth out the incorrect dynamics and give the appearance of a meaningful trajectory.
We happen to have seen a recent example here Fixing particles on wall - #11 by srtee where a combination of numerically aggressive boundary conditions, two aggressive walls and one aggressive thermostat led to “smooth” trajectories, with the only unexplained behaviour being a fictitious clustering of particles correlated with their initial positions.
Thank you very much for your comments. You are absolutely right—reducing the timestep from 5 fs to 1 fs significantly reduced the occurrence of dangerous builds to just one. However, further decreasing the timestep may increase the total simulation time. Would you recommend reducing it further to completely eliminate the issue while balancing the observation time?
This error comes from the time step! If the time step that you considered for your simulations is too large, you got this error. To avoid the atomic interactions, you can select smaller values for time step.