[lammps-users] neighbor list overflow

LAMMPS LAMMPS Mailing List Mirror
1

Hi all,

I’m recently trying to simulation a granular system with friction term only by the following codes:
units lj
atom_style sphere
read_data data.endofpushoff
change_box all triclinic
comm_modify vel yes
neighbor 0.3 bin
neigh_modify delay 0 every 1 check yes
pair_style granular
pair_coeff * * rog 0 85.73 tangential linear_nohistory 0.5 0.5 damping viscoelastic rolling sds 15000 0.5 0.005 twisting sds 15000 0.5 0.1
fix 1 all npt temp 0.0000001 0.0000001 10 x 0 .001 500 y 0 .001 500 z 0 .001 500 xy 0 0 500 xz 0 0 500 yz 0 0 500
timestep 0.005
thermo_modify lost warn
compute 1 all voronoi/atom
dump 1 all custom 10000 configs.dump id type x y z ix iy iz c_1[1] c_1[2]
thermo 100
thermo_style custom step temp etotal pe press vol lx ly lz xy xz yz pxx pyy pzz
run 200000
unfix 1
fix 2 all npt temp 0.0000001 0.0000001 10 x 0.001 .001 500 y 0.001 .001 500 z 0.001 .001 500 xy 0 0 500 xz 0 0 500 yz 0 0 500
run 13800000
write_restart restart.extend
write_data data.extend

The parameter in rog argument which is a normal contact model is kr and \eta_0 seperatly.

The simulations worked well when we setup as pair_coeff * * rog 15000 85.73 tangential linear_nohistory 0.5 0.5 and pair_coeff * * rog 15000 85.73 tangential linear_nohistory 0 0.

However, if we apply the above scripts, the simulation crashed and showed:
ERROR on proc 0: Neighbor list overflow, boost neigh_modify one (src/npair_half_size_bin_newton_tri.cpp:111)

Then I modified the command: neigh_modify delay 0 every 1 check yes page 80000 one 8000. But the running time is at least 4 times slower than the other two simulations. (The simulations have 10000 particles.)

I’d appreciate it if anyone could suggest the page value or any other methods to make it run well and fast.

Sincerely,
Kai

2

Kai,

the situation is usually not as simple as that we can give you a “magical” command or set of flags that will miraculously solve all your problems.
first you have to figure out not just what triggers the problem, but what is happening. the best way to do this is to visualize your trajectories.

you get a neighbor list overflow when there are (obviously) too many neighbors per atom. this is a very unusual situation for granular models, which typically have very few neighbors.
the only exception would be in cases of extreme poly-dispersity, i.e. having a few very large particles and then a large number of very small particles around it.

comparing the trajectories and their visualizations for the two different pair_coeff settings should provide the necessary insight.

possible solutions would follow from that. it would be unwise to speculate and describe possible approaches.