Dangerous build problem while running I-PI simulation with LAMMPS as a client

I am running an I-Pi simulation with LAMMPS as a client and I am getting a very high number of dangerous builds and tried to reduce neighbor and neigh_modify value, but still, the dangerous build is coming high. Is it normal for a dangerous build to have such high value for an I-PI simulation with Lammps as a client or there is some mistake with the methodology?

LAMMPS Output –
Total # of neighbors = 43060
Average neighs/atom = 224.27083
Neighbor list builds = 584746
Dangerous builds = 548086

LAMMPS Code –

bulk water

units metal
atom_style atomic
boundary p p p
read_data water.lmp

neighbor 2 bin
neigh_modify every 10 delay 0 check yes

mass 1 16
mass 2 1

pair_style deepmd …/240_25_viral/0.02_1_v/graph.pb
pair_coeff * *

timestep 0.00048

group Oatoms type 1
group Hatoms type 2

fix 1 all ipi localhost 8080 unix reset

thermo_style custom step temp ke pe etotal press vol
thermo 100
thermo_modify format line “d .6e .6e .6e .6e .6e .6e .6e .6e .6e”

dump my_dump all custom 100 lw_pimd.xyz id type x y z vx vy vz
dump_modify my_dump sort id
dump my_dump2 all atom 100 lw_pimd.lammps-dump-text

compute myRDF all rdf 100 1 1 1 2 2 2
fix 2 all ave/time 100 1 100 c_myRDF[*] file lw_pimd.rdf mode vector ave running

I-PI Code–
i-pi.xml (2.7 KB)

No.

Your input still states a value of 10 for “neigh_modify every”, which is quite high at a timestep of about 0.5fs.

There should be no dangerous builds with a suitable bin size (2 angstrom should be ok) and “neigh_modify every 1 delay 0 check yes”. The bin size needs to be larger with a larger timestep and a larger value of “neigh_modify every”. On the other hand, a larger bin size generates more neighbor list entries and thus more computations of distances between atoms that are likely outside the cutoff, so it can slow down the Pair part of the calculation, while it speeds up the Neigh part of a run. So there is an optimal balance. For your choice of timestep, a smaller value (e.g. 1.0 angstrom) may be just as well, provided “every” remains at 1 or 2 and delay is not boosted too much. It all depends on how expensive additional neighbors are for a given pair style versus the cost of the neighbor list checks and builds.

You can then look at the number of total neighbor list builds versus the number of timesteps in the run, to make a conservative choice for delay and use every at either 1 or 2. The check triggered by “check yes” is taking rather little time compared to the time for a neighbor list build. Add to that the law of diminishing returns, i.e. the savings of changing from delay 0 to delay 1 or delay 2 are the most. Increasing the delay does not help a lot and so does changing from every 1 to every 2, but they increase the risk of dangerous builds.

In general, a few dangerous builds do not automatically mean you are using incorrect neighbor lists. The check that is done is rather conservative. You need to worry the most, if your pair style requires neighbors of ghost atoms, which should be indicated in the neighbor list settings summary at the beginning of a run.