Dear Everyone,
I have a periodic system and use “fix deform” to apply tension.
I also use “neigh_modify delay 0 every 1 check yes.” Does this command indicate that Lammps will wrap the atoms that move across the boundaries back to the simulation cell every time step and rebuild the neighbor list?
Thank you very much for your help,
Lili
Dear Everyone,
I have a periodic system and use “fix deform” to apply tension.
I also use “neigh_modify delay 0 every 1 check yes.” Does this command indicate that Lammps will wrap the atoms that move across the boundaries back to the simulation cell every time step and rebuild the neighbor list?
No
Thanks Axel, then where can I get/ or set the frequency for Lammps to wrap the atoms back to the local box? Lili
Thanks Axel, then where can I get/ or set the frequency for Lammps to wrap
the atoms back to the local box? Lili
please read the documentation on neigh_modify more carefully.
but actually, i am wondering, what is your purpose on enforcing the
coordinate wrapping. it usually comes with a significant performance
penalty if done during the simulation and it can be easily and more
conveniently done after the fact, e.g. with the pbctools plugin in VMD.
usually writing out the trajectory with image flags and without enforcing
strict coordinate wrapping is the most flexible and accurate way to not
lose any information avoid additional effort and problems during analysis
and visualization.
axel.
Dear Axel,
Many thanks for your guidance. I re-read the “neigh_modify” doc, and understand the use of “check yes.”
The purpose I want to know at what time steps Lammps wrap the coordinates during the run is: our pairwise force values don’t match Lammps’ results (we use the unwrapped trajectory outputted from Lammps, then we wrap the atoms back to local box by ourselves). Therefore, I doubted our wrapping frequency is not the same as Lammps’ during the simulation.
In the “neigh_modify” doc page, there seems no explanation on the relation (if any) between the neighbour list re-build and wrapping atoms for periodic conditions.
I will see if I can use image flags instead of wrapping atoms by myself.
Thank you very much,
Lili
LAMMPS wraps atoms back into the periodic box whenever it
reneighbors. Just b/c you check for reneigh every step, doesn’t
mean it will reneighbor every step. So you should just let
LAMMPS decide that. Wrapping atoms back into the periodic
box does not affect the forces on the atoms.
Steve
Dear Axel,
Many thanks for your guidance. I re-read the "neigh_modify" doc, and
understand the use of "check yes."The purpose I want to know at what time steps Lammps wrap the coordinates
during the run is: our pairwise force values don't match Lammps' results
(we use the unwrapped trajectory outputted from Lammps, then we wrap the
atoms back to local box by ourselves). Therefore, I doubted our wrapping
frequency is not the same as Lammps' during the simulation.
what do you mean by "*our* pairwise forces"? and what is the meaning of
"doesn't match"? since you are doing floating-point math (which is not
associative and has truncation errors when summing up numbers of different
magnitude), you cannot expect *exact* matches. you get similar magnitude
differences, when using a different number of processors when running in
parallel or switch between having the origin in the lower left front corner
of the box and in the center of the box.
in any case, with properly implemented periodic boundary conditions, it
should not matter (within the limitations of floating point math) whether
you have unwrapped or wrapped coordinate data and how often you "rewrap"
coordinates (as part of rebuilding the neighbor lists).
In the "neigh_modify" doc page, there seems no explanation on the relation
(if any) between the neighbour list re-build and wrapping atoms for
periodic conditions.
this information is on the doc page for the dump command (where it
belongs):
IMPORTANT NOTE: Because periodic boundary conditions are enforced only on
timesteps when neighbor lists are rebuilt, the coordinates of an atom
written to a dump file may be slightly outside the simulation box.
in other words,
during the neighbor list build, atoms that have left the box are exchanged
between neighboring subdomains, that forces all local atoms to be inside
the subdomain (and thus the entire set of local atoms in the total
simulation cell).
I will see if I can use image flags instead of wrapping atoms by myself.
i don't understand what that would accomplish.
axel.