I am trying to merge two data files using the read_data… append… shift command. One file is a data file produced by moltemplate (heretofore, moltemplate data file). The other is a data file written from a previous simulation using the write_data command (heretofore, data.restarter file).
In the script for this merged-simulation-box, I added a write_data line before minimization in order to visualize the system as it is read from the data files before anything else takes place. Visualization in Ovito confirms there are no overlap atoms (i.e. the shift worked correctly), but the part of the simulation box created from the data.restarter file has “crazy” bonds. The part of the simulation box created from the moltemplate data file looks fine.
I recall from previous Ovito experience that the “crazy” bonds problem can be worked around by sorting the lammps data file by particle ID, so I tried that approach manually here, but it did not work. Specifically, I sorted the data.restarter file “atoms” section by ascending atom number.
Any pointers on resolving this, either by after the fact editing of the data file or by preventing it from happening in the first place with a modified write_data format, would be appreciated.
Simulation input and output files can be accessed via my proton drive link below:
Sean, please carefully check your data files, if they have image flags on the coordinates that are non-zero. If there are, this can lead to lots of trouble with read_data append.
Not for data files. The bond data identifies atoms by the atom ID, their order does not matter. This is only an issue with dump files that are lacking the atom ID.
I see, thanks for that. Yes, I do have non-zero image flags. Would the reset_atoms command just set those to zero? Or is it more complicated than that?
It is more complicated than that. If you just set them all to zero (you can do that with the set command — LAMMPS documentation), you can end up with similarly unwanted bonds that cross the system.
Please check the docs.
The basic problem with read_data append is that it will expand the box, but not remap the atoms before that. If a box gets expanded, that “moves” the atoms with non-zero image flags. The image flag is essentially a short cut for “add n times the length of the box”, but if the box grows by 50% suddenly an additional distance of 310 angstroms becomes 315 angstroms and while for the atom next to it which has an image flags setting of 210 angstroms, which becomes 215, so atoms that were previously about 1-2 angstroms apart are suddenly 5 angstrom further apart.
I downloaded the Dec2022 version and added the following line to my code, immediately following reading in the data files, settings, and charges and prior to minimization:
reset_atoms image all
The code then immediately outputs a data file and proceeds to minimize and run. Two warnings and an error print:
WARNING: Inconsistent image flags (src/domain.cpp:815)
WARNING: Bond/angle/dihedral extent > half of periodic box length (src/domain.cpp:936)
Per MPI rank memory allocation (min/avg/max) = 263.6 | 263.6 | 263.6 Mbytes
Step Time Temp Press Enthalpy Volume Density TotEng
1000 1000 280.10126 -803815 69135905 13322794 0.13035826 2.2531659e+08
ERROR: Domain too large for neighbor bins (src/nbin_standard.cpp:133)
Last command: run 2000
I also noticed for some reason I have a very large net charge in my system, which I’ll have to trace the origin of–I’m assuming that is an isolated issue from the image flags and domain error.
That won’t do, and this is not what I suggested you do. The problem happens when reading the second data file and after you have read it in, you cannot undo what get broken in the process. You must correct each data file individually and before reading in both in such a way that there are no non-zero image flags. With the reset_atoms command you can minimize them, but there may be a few that you have to correct manually (just write out the unwrapped coordinates with a dump command and replace them in the data file. after that manually increase the box dimensions so that all atoms fit in).
Operating on each data file individually, in its own separate script to modify it before running a new simulation with the modified version, I am still getting non-zero image flags all over the place. I did what you said about dumping the unwrapped coordinates, and I can replace the coordinates for each atom with non zero image flags manually, but this is a little tedious and prone to error. I added my new input script and corresponding output data file to my proton drive folder (link above) if that would help to see what I’m getting. The names of the newly added files are:
polysystem76_prep2.in
dataNEW.restarterAAPoly76_1a
Apologies if I am being dense… “please be patient, new driver”
I’ve looked at your files, made some experiments and have to conclude that you are dealing with a challenging problem. There are multiple contributing factors.
You are using an unusual system of atom type / force field parameter setup, where you have the whole set of parameters always in use, even if your system has only a few of them. That is wasting some performance, but also collides with most tools and approaches to merge settings and parameters. Also, the way how you assign charges with many “set” commands instead of storing them in the data file is unusual.
The system that you want to add to the first system has a very different shape and is a complex polymer that is stretched out over multiple periodic images, so that in the principal simulation box, you have atoms from multiple instances of this polymer. That makes the usual methods fail, which assume you have atoms or many small molecules.
The box dimensions in x and y for the two systems are not quite compatible. So it is difficult for me to guess what is your intention for the final system to look like.
I don’t think there is an easy way to merge the two systems in a (semi-)automatic fashion.
My suggestion would be the following. create for each system a custom style dump file, that writes out the unwrapped coordinates without image flags in the same way as the data file requires it, e.g. using something like this:
write_dump all dump.unwrap custom id mol type charge xu yu zu modify sort id
Since you want to move the atoms in one of the two systems, you should probably also use the “displace_atoms” command to apply a suitable shift before writing the dump file. BTW: If I am seeing it correctly, then the shift you are using in your input is by about 5 angstroms too short.
With a atom data formatted this way, it should be possible to take your data files and replace the body of your Atom section with the body of the corresponding dump file.
Once you have done this, you can edit the box dimension any which way you like without deforming the system, since there are no more image flags (they are all implicitly set to zero). You need to edit the box dimensions in both modified data files so that they are exactly the same. You probably want to change the order in which you load those files and adapt the box for the second so it matches the first in x and y and then expand the box in z for both as needed.
If that all works out as expected, you can use read_data for both files and neither will the box be expanded or modified nor do atoms need to be shifted. Since you don’t have image flags but explicit unwrapped coordinates there is no problem and upon reading the data file, LAMMPS will wrap the coordinates and re-compute the image flags.
This is all rather complicated and error prone, but I cannot think of a simpler way. It may be a good idea, to practice this with a much smaller system first (just a few 10s of atoms each), so it is easier to double check everything.
