Issue with unwrapped coordinates

Hi,

I have a system consisting of 4 atom types and I am dumping their coordinates (unwrapped in x and y, wrapped in z) using the dump command in an NVT simulation. I find that the order in which the atom coordinates are dumped is different at various timestamps when compared to the first timestamp (i.e. at t=0) or the atom list I initially specify. I can't figure out why this is happening specifically for unwrapped coordinates nor could I find any previous observation of this issue on the forums/mailing list.

The specific dump command I use is:

dump 2 all custom 20000 coord_relax.xyz type xu yu z

I've attached the coord_lammps.dat (initial coordinates, atom types and bonding information) and the input_lammps.dat (simulation parameters) files for reference.

Thank you.
Shubhaditya

input_lammps.dat (4.08 KB)

coord_lammps.dat (114 KB)

Hi,

I have a system consisting of 4 atom types and I am dumping their coordinates (unwrapped in x and y, wrapped in z) using the dump command in an NVT simulation. I find that the order in which the atom coordinates are dumped is different at various timestamps when compared to the first timestamp (i.e. at t=0) or the atom list I initially specify. I can't figure out why this is happening specifically for unwrapped coordinates nor could I find any previous observation of this issue on the forums/mailing list.

the ordering of atoms in dump files has nothing to do with them being
wrapped or unwrapped. atom order is in order of how they are stored
internally, as that is much more efficient and requires less storage.
however, there is the option to request sorting of a dump (and if you
sort by id, you will have consistently ordered atoms in the
trajectory). in general, if you also dump the atom id, it is easy to
reorder atoms upon reading and that is rather efficient, as that is
usually done in serial. anyway, if you want sorted trajectories, look
at the dump_modify command documentation.

BTW: unlike your claim, this issue has been discussed rather
frequently on the mailing list.

axel.