Hello,
I am having an issue with the replicate command in lammps not assigning all atoms correctly. I found a few previous threads which mentioned that if there are atoms outside of the non-periodic boundaries this could cause the error so I tried to expand my shrink-wrapped boundary (and changed it to a m boundary instead of s) to make sure this wasn’t the case but I still get the error. I am only trying to replicate in the periodic directions. Below is my code;
Initialization
units metal
boundary m p p
atom_style atomic
pair_style eam/alloy
lattice fcc 3.52
Set up Simulation box
The structure is already minimized
read_data /fslhome/jbair34/compute/lammps/mobility/p220/ni.220.f.data
pair_coeff * * /fslhome/jbair34/compute/lammps/mobility/p220/ni1.set Ni Ni Ni Ni Ni
change_box all x delta -3 3
replicate 1 4 4
and the error:
LAMMPS (30 Jul 2016)
Lattice spacing in x,y,z = 3.52 3.52 3.52
Reading data file …
orthogonal box = (-65.1044 0 0) to (130.804 36.9181 41.6492)
6 by 1 by 2 MPI processor grid
reading atoms …
27620 atoms
reading velocities …
27620 velocities
Changing box …
orthogonal box = (-75.6839 0 0) to (141.384 36.9181 41.6492)
Replicating atoms …
orthogonal box = (-75.6839 0 0) to (141.384 147.672 166.597)
3 by 2 by 2 MPI processor grid
0 atoms
ERROR: Replicate did not assign all atoms correctly (…/replicate.cpp:383)
Has anyone had any similar issues and know how to fix it?
Thank you,
Jake Bair
please try with the very latest LAMMPS release to see, if the problem persists.
if not, please post your data file, so that we can have a closer look
at it and the replication code.
thanks,
axel.
and one more suggestion: try inserting a "run 0" command after change_box.
axel.
I tried those things and still get the error... I would paste it again but with the exception of the new stuff from the run 0 it is exactly the same with the newer date at the top. I am attaching the .data file that I am reading from for the initial positions. Please let me know if you find anything when you get a chance. Also let me know if you need more information.
Thank you,
Jake
ni.220.f.data (1.93 MB)
I think it has to do with your x boundary = “m”. Will investigate.
Steve
Here is the issue:
The replicate doc page says:
Bonds and other topology interactions are created between pairs of new atoms as well as between old and new atoms. This is done by using the image flag for each atom to “unwrap” it out of the periodic box before replicating it.
You box boundaries are m p p
which means the x dim is not periodic.
However your data file has x image flags of 212 for all the
atoms. So when those atoms are unwrapped during replication
they get x coords that are 212 box lengths away. When they
are put into the new replicated box, they are (far)
outside the new box in a non-periodic dim. Hence they are lost.
So the 1st Q is why are you starting with atoms that are 212x outside
the original box in a non-periodic dim.
If that is unavoidable, you could just set the x image flags to 0
for all the atoms via the “set” command after reading the data
file and before using the replicate command.
E.g. adding:
set group all image 0 NULL NULL
then it works fine.
Steve
Hi Steve,
I am sorry I don’t understand. The .data file has an x-min of -65ish and a x-max of 130ish and the x-min and x-max values for the atoms in the .data files that I can find are within 1 angstrom of those values. The boundaries were shrink wrapped and my understanding of the issue was if I expand the box to include those atoms that were outside it it would work. But as far as I can tell the change box command will re-shrink wrap the box if I use the s boundary so I switched it to the m boundary which is like shrink wrap but with a minimum and maximum number right? I thought what I did would use basically the same boundaries but expand the box by a few angstroms in the x direction so that it could be replicated in the y and z. I don’t know what you mean that they are 212 x outside the box because I am not replicating the x dimension only the y and z…? I am sorry I am pretty new to this still so I appreciate your help. Basically I want to replicate the data in the y and z direction to make a 1x4x4 grid of the original boxes to do a larger simulation.
Thanks,
Jake
Hi Steve,
I am sorry I don't understand. The .data file has an x-min of -65ish and a
x-max of 130ish and the x-min and x-max values for the atoms in the .data
files that I can find are within 1 angstrom of those values. The boundaries
please look at the last 3 columns of your Atoms section.
were shrink wrapped and my understanding of the issue was if I expand the
box to include those atoms that were outside it it would work. But as far as
I can tell the change box command will re-shrink wrap the box if I use the s
boundary so I switched it to the m boundary which is like shrink wrap but
with a minimum and maximum number right? I thought what I did would use
basically the same boundaries but expand the box by a few angstroms in the x
direction so that it could be replicated in the y and z. I don't know what
you mean that they are 212 x outside the box because I am not replicating
the x dimension only the y and z...? I am sorry I am pretty new to this
still so I appreciate your help. Basically I want to replicate the data in
the y and z direction to make a 1x4x4 grid of the original boxes to do a
larger simulation.
please do the following test:
set your boundary to "p p p", then load the data file and then use
write_dump to output the coordinates, but output them as xu yu zu,
i.e. _unwrapped_ coordinates and compare those numbers to what you get
with x,y,z (which should be what you have in your Atoms section of the
data file).
it appears, that you are using a data file taken from all-periodic
simulation run, where atoms have passed through periodic boundaries
many times.
for non-periodic boundaries, they cannot happen and thus LAMMPS is
thoroughly confused by having coordinates that are, when unwrapped,
are far outside the simulation box and thus should be ignored.
this is why steve suggested, that you first reset your image flags for
the non-periodic dimension (and it may possibly best to do it for
all).
axel.
Thank you for the explanation. I still don't understand what the unwrapped positions mean but that does help. The odd thing is that the initial simulation used s p p boundaries, not p p p boundaries. I am reading data from a minimized bicrystal as calculated by Olmsted in his GB energy paper several years ago which cannot have periodic conditions in the x direction. So when I reset the flags it does work but I am confused about why it had those issues in the first place? The issue seems to be fixed so you don't need to answer this if you don't want and I will read up on the unwrapped positions to find an answer. I appreciate all of the help both of you have given.
Thanks!
Jake
Thank you for the explanation. I still don't understand what the unwrapped positions mean but that does help. The odd thing is that the initial simulation used s p p boundaries, not p p p boundaries. I am reading data from a minimized bicrystal as calculated by Olmsted in his GB energy paper several years ago which cannot have periodic conditions in the x direction. So when I reset the flags it does work but I am confused about why it had those issues in the first place? The issue seems to be fixed so you don't need to answer this if you don't want and I will read up on the unwrapped positions to find an answer. I appreciate all of the help both of you have given.
your data file at the very top says:
LAMMPS data file from restart file: timestep = 299, procs = 1
so that means, the data file was generated from a (binary) restart
file. i can see two possible ways to have non-zero image flags:
1) the atoms have passed through periodic boundaries, typically due to
some significant residual center of mass momentum that wasn't removed
properly or has accumulated for other reasons
2) you have converted a binary restart file that was generated by a
different version of LAMMPS where in between the format had changed.
then the code generating the data file would just read random bytes
from memory.
you can learn more about unwrapped coordinates and image flags in the
documentation for read_data, dump and a few other places (e.g. compute
msd).
axel.