fix pour: particles overlapping at z periodic boundary

Hi,

We are experimenting with inserting particles into a periodic cell between pre-existing particles using fix pour. We have found that fix pour can insert particles over the x and y periodic boundaries without overlapping particles on the other side of the boundary, but is unable to do this with the z-boundary. The code is below (tested with the latest stable release), I can provide the input data by email or send to the list (122kb). From the dump file you will see that particles close to the z-boundary have very high stresses as they overlap on placement.

I note that the issue with the side boundaries was noted before https://lammps.sandia.gov/threads/msg43509.html and I appreciate that fix pour was not probably not intended for use with a z periodic boundary, but any help fixing this would be greatly appreciated.

Best wishes,

Tom Shire

Initialisation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

units si

boundary p p p

atom_style sphere

dimension 3

newton on

comm_modify mode single vel yes

Create particles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

read_data Particle_Coordinates.lj

neighbor 1e-3 bin

neigh_modify delay 0 every 1

pair_style gran/hooke/history 1e8 NULL 50.0 NULL 0.5 1

pair_coeff * *

timestep 1.5e-9

run_style verlet

fix 3 all nve/sphere

fix grav all gravity 0.0 vector 0 0 -1 # set to zero so particles don’t move in periodic cell

variable step equal step

variable xlength equal lx

variable ylength equal ly

variable zlength equal lz

variable particles equal atoms

variable steps equal 5

compute stress all stress/atom NULL pair

compute 5 all stress/atom NULL pair

dump 1 all custom 1 dump.stress id x y z diameter c_stress[1] c_stress[2] c_stress[3]

run 1

####################### ADD NEW PARTICLES #########################

region myreg1 block 0 1.60626 0 1.60626 0 0.5

fix pour1 all pour 1000 1 413554 region myreg1 diam one 0.01 dens 2650 2650

run 1

tom,

a quick glance at the source code shows that for your settings, the z direction should be treated essentially the same as x and y. so either some of your settings are not what you think they are or there is something not obvious happening in the source code (e.g. something is not properly initialized).

the best way to proceed with an issue like yours, where you have a simple way to reproduce it, would be report this as an issue on github ( https://github.com/lammps/lammps/issues ) and attach your input deck and output as compressed archive or .txt files. that would guarantee that this is being looked at (at some point). e-mails have a tendency to disappear from the view of busy people if they cannot look into it immediately :wink:

axel.