Dear LAMMPS users,
I post a question in the LAMMPS mailing List concerning the conversion of a restart file to data file.
More specifically, in a first simulation (which I had initially 64 molecules, 22528 atoms, 25664 bonds, 41600 angles, 63744 dihedrals and 12800 impropers)
I deleted 4 molecules with the delete_atoms command and the simulation was succesfully executed.
When I tried to convert the final restart file to data file the problem that I faced was the following:
The number of atoms, bonds and angles are the correct ones (21120 atoms, 24060 bonds and 39000 angles) but the number of dihedrals and impropers
are equal to the old data file (63744 dihedrals and 12800 impropers).
The strange thing is that in the connectivity part of the data file the dihedrals and impropers are correct (59760 dihedrals and 12000 impropers).
Is there any explanation of this?
Also, another thing that I want to state is that if I want to use the restart file to start another simulation in which I want to give the initial velocities
I take a message that the velocities cannot be attributed to the atoms because the ID’s of the atoms are not consecutive.
Thank in advance for your support.
Best regards,
Emmanuel N. Skountzos.
first off, there are two very important pieces missing in your e-mail.
1) you don't specify which version of LAMMPS you are using and whether
the issue persists with the very latest development version of LAMMPS.
2) you don't provide a simple example that reproduces your issues, so
that people can take a closer look.
axel.
Dear Axel,
-
I am using the 1 Feb 2014 version of LAMMPS.
-
I have noticed the same problem to a couple of systems I have simulated.
One of them is the one I mentioned in my previous mail (concerning the number of
molecules, atoms etc). I performed an NPT simulation of this system at P=1atm and T=600K.
If you need any further information to provide to you please let me know.
Best regards.
Emmanuel N. Skountzos.
Στις 2015-07-09 23:22, Axel Kohlmeyer έγραψε:
Still not clear to me
To clarify:
1) You ran LAMMPS to load a data file and then used the delete_atoms
command to delete 4 molecules.
2) Then you used the write_restart command.
3) Later you read_restart command and notice the number of dihedrals
and impropers is incorrect?
4) Later on, you using write_data command (instead of the
write_restart) command.
5) You used the read_data command and noticed that this time the
number of dihedrals and impropers is correct?
Is this correct?
At no point you were using the "restart2data" tool?
http://lammps.sandia.gov/doc/Section_tools.html#restart
(Don't use it by the way.)
Andrew
Dear Axel,
- I am using the 1 Feb 2014 version of LAMMPS.
Far too old for what you want to do.You have to update.
Dear Andrew,
I am really sorry I was not clear. The procedure I follow is:
-
In the .in file I load a data file (let’s say data1.dat) which has 64 molecules (22528 atoms, 25664 bonds, 41600 angles, 63744 dihedrals and 12800 impropers)
-
In the .in file after the read_data command, I have grouped the specific molecules I want to delete (for example 24 31 45 63) in group named “deleted_atoms”
-
In the .in file again with the delete_atoms command I choose to delete the atoms belonging to “deleted_atoms” group.
-
I execute the simulation, everything runs normally (with the correct number of atoms as the log.lammps file informs me).
-
When the simulation finishes I take the last_conf.rst file and I type the following command in the folder that I have the executable:
./lmp_mpi -r last_conf.rst last_conf.data
- When I open the last_conf.data the number of atoms, bonds and angles in the beginning of the file, are correct. The number of the dihedrals and impropers
though are those of the data1 file (i.e. it has more number of dihedrals and impropers that it should have)
- When I go down to the connectivity part though, I notice that the number of dihedrals and impropers are the correct ones and different
to those specified in the beginning of the last_conf.data file.
Please let me know if I didn’t get clear again.
Best,
Emmanuel N. Skountzos.
Στις 2015-07-10 01:04, Andrew Jewett έγραψε:
emmanual,
here is the protocol what to do when you think you have found a bug in
LAMMPS (or a problem, that you don't know how to solve).
step 1: go to http://lammps.sandia.gov/bug.html and check if there is
a report for a bug that could be related to your problem has been
fixed. if your version is old, you may have to look at the
corresponding pages for the previous year(s). in your case, you should
have seen that the option to delete bonds/angles/dihedrals/impropers
together with atoms was only added at the beginning of this year. so
your simulation is actually bogus (despite no error or not having
crashed).
step 2: try to reproduce the issue with the latest version. download a
precompiled serial executable if needed. it can even be on a different
platform, and check if the problem persists. (in this case, you should
have seen that the count issue has been resolved. the fact that your
bonds were deleted was by chance. bonds/angles/dihedrals/impropers are
usually "owned" by one single atom. if you delete that atom, you
delete the bond. had you deleted the other atom, the bond remains).
step 3: if step 2 didn't help, you need to drill down your input to
the smallest possible input deck that can reproduce the problem., e.g.
in your case two molecules and you delete one of them. and then post
input and data file, so that it can be run and quickly debugged, if
needed.
that is it.
as for the velocity command failing. it is difficult to tell, but that
should only apply to the "loop all" flag, which does require
consecutive atoms, or else it cannot produce the desired distribution
without a prohibitive amount of communication.
axel.
That's clear to me now. Thanks. Still no idea why this is hapenning.
If you want to file a formal bug report, download the latest version
of LAMMPS, and make a small test case (small number of atoms, short
simulation times, if any). It's more work for you, but that will
greatly increase the chance of it being resolved.
Thanks for posting.
Andrew
A list of personal rants about the perils of restart files:
http://lammps.sandia.gov/threads/msg51612.html
http://lammps.sandia.gov/threads/msg47581.html
rant:
Restart files are a cool idea, but unless I specifically need them, I
think it's safer to use data files. (write_data and read_data
commands.) I also prefer to save the force-field parameters
separately in a LAMMPS input script. (...where they can't get
accidentally messed up during writing and subsequent reading. My
experience is there more likely to be a bug in the code that reads and
writes force field information from restart files and data files,
compared to the code that reads LAMMPS input scripts. For this reason
I'd like to add an option to "write_data" so that there is some way to
omit all the "Coeffs" in the data file. I realize that has nothing to
do with your issue. Until then, I think you should be able to delete
them afterwards in the shell using:
extract_lammps_data.py -n
"Pair Coeffs" "Bond Coeffs" \
"Angle Coeffs" "Dihedral Coeffs" "Improper Coeffs" \
< file.data > new_file.data
mv -f new_file.data file.data
(You can use the lammps "shell" command to invoke these commands from
within a LAMMPS input script.)
[...]
commands.) I also prefer to save the force-field parameters
separately in a LAMMPS input script. (...where they can't get
accidentally messed up during writing and subsequent reading. My
there is another issue at hand, that a lot of flags that one would
expect to be in the restart aren't and others do show up unexpectedly
or unwanted.
restart files are a necessity for large simulations and quite a few
scenarios. what is a problem is the current rather ad-hoc format.
experience is there more likely to be a bug in the code that reads and
writes force field information from restart files and data files,
compared to the code that reads LAMMPS input scripts. For this reason
I'd like to add an option to "write_data" so that there is some way to
omit all the "Coeffs" in the data file. I realize that has nothing to
do with your issue. Until then, I think you should be able to delete
them afterwards in the shell using:
extract_lammps_data.py -n
"Pair Coeffs" "Bond Coeffs" \
"Angle Coeffs" "Dihedral Coeffs" "Improper Coeffs" \
< file.data > new_file.data
mv -f new_file.data file.data
why on earth do you want to do such a messy and ugly hack, when
<10mins (inlcuding updating the docs and running a quick test) with
the source code can solve this properly? 
check this out...
diff --git a/doc/write_data.txt b/doc/write_data.txt
index d914fe4..b22a42c 100644
--- a/doc/write_data.txt
+++ b/doc/write_data.txt
@@ -14,7 +14,8 @@ write_data file keyword value ... :pre
file = name of data file to write out :ulb,l
zero or more keyword/value pairs may be appended :l
-keyword = {pair} :l
+keyword = {pair} or {nocoeff} :l
+ {nocoeff} = do not write out force field info
{pair} value = {ii} or {ij}
{ii} = write one line of pair coefficient info per atom type
{ij} = write one line of pair coefficient info per IJ atom type pair :pre
@@ -77,6 +78,11 @@ data file is read.
:line
+The {nocoeff} keyword requests that no force field parameters should
+be written to the data file. This can be very helpful, if one wants
+to make significant changes to the force field or if the parameters
+are read in separately anyway, e.g. from an include file.
Incidentally, perhaps the problem lies not in write_restart.
This reminds me of a similar problem Arun posted about write_data &
read_data posted last August. I don't know if that ever got resolved.
http://lammps.sandia.gov/threads/msg48060.html
(Arun, if you're reading this, what version of LAMMPS were you using
at the time?)
-Andrew
why on earth do you want to do such a messy and ugly hack, when
<10mins (inlcuding updating the docs and running a quick test) with
the source code can solve this properly?
check this out...
If you can get this into the main codebase, then that's great!
Thank you
Andrew
I had made almost identical changes to write_data.cpp and
write_data.txt for personal use, but did not submit the code for
inclusion in LAMMPS.