Bond atoms missing on proc

You are working in lj units and neighbour skin is 2?

please have a look here

http://lammps.sandia.gov/doc/neighbor.html

Arun

Hi,

I had already seen that part of the documentation but I am still confused. If the atoms are only communicated to new processors on time-steps where the neighbour lists are rebuilt, should I reduce the skin distance such that neighbour lists are rebuilt more often? I have tried running with the ‘check’ option set to ‘no’ so that the neighbour lists are built every time-step but I still get the same error. Also, the log.lammps file indicates that the max number of neighbors per atom is 2000. May I know how this value was obtained?

Best,

Karthik.

Hi,

I had already seen that part of the documentation but I am still confused. If the atoms are only communicated to new processors on time-steps where the neighbour lists are rebuilt, should I reduce the skin distance such that neighbour lists are rebuilt more often? I have tried running with the ‘check’ option set to ‘no’ so that the neighbour lists are built every time-step but I still get the same error. Also, the log.lammps file indicates that the max number of neighbors per atom is 2000. May I know how this value was obtained?

Best,

Karthik.

Hi,

I had already seen that part of the documentation but I am still confused.
If the atoms are only communicated to new processors on time-steps where
the neighbour lists are rebuilt, should I reduce the skin distance such
that neighbour lists are rebuilt more often?

​the neighbor list skin in LAMMPS serves three purposes.
1: it defines a "safety margin" for building ​neighbor lists, to make
certain that all relevant neighbors are contained.
2: it also serves as a threshold for when neighbor lists need to be rebuild
3: it sets the default for the "ghost cutoff", i.e. the distance up to
which subdomains are surrounded by copies of atoms from neighboring
subdomains

the 1st function is practically always given because of the application of
#2.

the 2nd function is an optimization. the larger the skin distance, the
fewer times neighbor lists need to be rebuilt, so this can save time.
however, the downside of a large neighbor skin is that your neighbor lists
grows larger, and you have to look at many more potential neighbors, which
costs time. there is an optimum here, that can be empirically found. for
your system it seems to be somewhere between 0.75 and 1.0. it should be
large enough, so you do not get any "dangerous builds".

​the 3rd function, however, is what triggers​ the error message you are
seeing. you have a bond that straddles two subdomains and that has become
too long, so that one of the two atoms forming the bond is no longer within
the surrounding ghost atoms. increasing the skin will increase that
distance, too. but see above about the negative performance impact.
an alternate way to increase this ghost atom cutoff is to use
comm_modify cutoff ...
that will not affect the neighbor list.

however, you need to look into *why* your bonds are becoming so large.
writing out a trajectory and visualizing it might help understanding what
is going on. often this happens due to incorrect or unsuitable force field
parameters or settings. sometimes also the time step can be chosen too
large or correspondingly the mass(es) too small. also, you need to monitor
more properties than just temperatures. the evolution of the potential
energy, pressure, bonded vs. non-bonded energy all provide useful
information. e.g. your system has a very high pressure, which would hint a
either a badly chosen initial density or bad parameters.

but you yourself are in the best situation to determine and check this.
BTW: unlike your claim, your bond force constant is 20 epsilon, not 40.

I have tried running with the ‘check’ option set to ‘no’ so that the
neighbour lists are built every time-step but I still get the same error.
Also, the log.lammps file indicates that the max number of neighbors per
atom is 2000. May I know how this value was obtained?

​this is an input parameter. neigh_modify one 2000 is the default. LAMMPS
uses a tiled memory management for neighbor lists. it will tell you, when
the default setting is insufficient. for your kind of system with a short
cutoff, this is extremely unlikely to happen.​

​axel.​

Dear all,

I am still not able to pinpoint the reason for the bonds becoming so long such that one of the atoms forming the bond is not within the surrounding ghost atoms. I have tried reducing the time-step by a factor of 10 to 0.004 and increasing the spring force constant up to 80 to limit the extent to which the bonds can stretch but the same error still occurs.

The density of the system is chosen to be 3.0/(rc^3). The initial configuration is set up as follows: The first bead of each polymer chain is inserted at a randomly chosen location in the simulation box and the remaining beads in the chain are inserted using a 3D self-avoiding random walk. All the initial bond lengths are chosen to be at the equilibrium value. The solvent beads are then placed randomly within the box. It is ensured that the distance between any two beads in the initial configuration is at least 0.2.

I have tried to visualize the trajectories of the chains prior to the occurrence of the error but nothing seems obviously wrong in that the chains don’t seem to be breaking up and all the bonds are still intact. I have previously performed this simulation using DL_MESO (another DPD software) and I have some idea of what the mean square radius of gyration should be. The mean squared radius of gyration evaluated based on the LAMMPS trajectory data before the occurrence of the error is significantly smaller than expected. At the same time, it seems I also have a problem with the bonds becoming too long, so I am not sure what the issue is.

Best,

Karthik.