use of label in read_dump

LAMMPS LAMMPS Mailing List Mirror
1

Hello people,

I'm a new lammps user. My question may have come up before, but I couldn't find an answer searching the archives. So here comes possibly a repeat.

I seem to have trouble using the label keyword in read_dump. Reading x y and z works fine. But no matter what I try for other atom properties (in my case id, type and charge for the COMB potential) via the label keyword, lammps tells me

ERROR: Illegal read_dump command (../read_dump.cpp:638)

The atom lines in my dump flle are structured like

ITEM: ATOMS id type x y z fx fy fz q
1 2 0 0 1 0 0 0 0.0190296
2 2 9.0245 1.8049 1 0 0 0 0.0187838
3 2 43.3176 3.6098 1 0 0 0 0.0195439
4 2 45.1225 5.4147 1 0 0 0 0.017334
5 2 0 7.2196 1 0 0 0 0.0178658
.
.
.

If I wanted to read more than just x, y, z, then how to add the instruction for reading id, type and q using the label keyword to the only line that I could get lammps to accept:

read_dump dump-start 0 x y z add yes

No matter where I place 'label [values for whatever property]", lammps spits it out with a Illegal read_dump command. Though it sounds perhaps a bit silly to put something as elementary as this here, could someone suggest how I could make lammps read in anything beyond x,y,z please?

I'm using a lammps executable I built a few months ago when I started using lamps, no other versions ever. So I presume that it wouldn't be a matter of code changes in lammps that make me combine now incompatible dump/in files with a wrong executable version.

greets,
Peter

2

You’re getting an error, b/c the read_dump command
doesn’t support reading any per-atom fields other
than the ones it lists on its doc page. Q is not listed.

The assumption is that you have already defined your
system, and just want to use the dump file to
overwrite the atom coords or velocities. Thus you
should already have a system with atom types and
charges. COMB re-computes the charges anyway,
so why do you need to read them in?

Steve

3

Thanks Steve, that helps.

The charges can be useful for systems where convergence is difficult. Starting from scratch, the algorithm can take a number of steps to converge to the set criterion (I'm using COMB3 which wasn't part of the standard distribution yet, I don't know how to increase the default maximum number of qeq iterations of 20), or fail all together. Starting from previous saved charges can help make things go better.

And without ID, the atom numbering get hussled up. I coudn't get id and type to work either btw, so if you could suggest the correct syntax for that, it would make one newbie vey happy. :slight_smile:

greets,
Peter

4

Read dump does read the ID, that’s how it knows what

atom to assign the new coords to. You just don’t have
to specify it in the command itself.

It wouldn’t be hard to have it read Q, it would just
have to be added to the code for read_dump.cpp.

Steve

5

Read dump does read the ID, that's how it knows what
atom to assign the new coords to. You just don't have
to specify it in the command itself.

It wouldn't be hard to have it read Q, it would just
have to be added to the code for read_dump.cpp.

and what should work right away is to use data files. either using
restart2data off a restart file or with write_data.

if you don't have any bonds, it could also be straightforward to read
the dump into VMD and save it as a charge style data file with the
topotools plugin.

axel.

6

Hi Axel,

Thanks for your reply. The reason I was trying to use dump text files is that they can be made to be written at start, intermediate stages and end, without needing to convert from binary files. Not that conversion from binaries is a big effort, what you suggest works perfectly fine of course (very tiny thing is that the restart command doesn't have an accompanying option like dump_modify to sort the output according to atom id, right?). But having only one text file format involved from beginning to end does seem very practical. The lammps manual says that write_data functionality will be extended (at the moment there really is no way to make it produce files periodically, right?). Once that is done, that should give me what for my work seems the ideal practical scenario.

Until then, at the risk of seeming stubborn, it seems dump files should offer me the option I'm looking for. From what Steve wrote, I understand now that reading charge was never going to work. But id and type should. And it seems that's all that is missing for me right now. If I start from a dump file reading in just x, y and z with the input line

read_dump dump-start 0 x y z add yes

the atom ids get messed up. In my initial dump file (not reading any structure file through read_data), the last few lines of my system are

6238 2 39.7078 52.3421 27.8434 8.27188e-08 -5.25299e-07 -0.000139169 0.0132712
6239 2 45.1225 50.5372 27.8434 1.75151e-08 1.98775e-06 -0.000139557 0.0153997
6240 2 43.3176 52.3421 27.8434 1.38936e-06 -4.92382e-07 -0.000138153 0.0137494
6241 3 7 9 28.5 -58.4792 -6.96921 174.279 0
6242 3 22.5 9 28.5 32.7348 -0.851364 24.3077 0
6243 3 39 9 28.5 -46.608 -1.48362 39.1276 0
6244 3 7 27 28.5 -57.5051 -18.9934 170.027 0
6245 3 22.5 27 28.5 32.3661 -2.5265 23.9976 0
6246 3 39 27 28.5 -46.0426 -4.38918 38.5888 0
6247 3 7 45 28.5 -55.3075 -30.132 162.928 0
6248 3 22.5 45 28.5 31.6533 -4.10018 23.3929 0
6249 3 39 45 28.5 -44.9383 -7.11559 37.5379 0

The system is 6240 Cu atoms (type 2) that form a substrate, 9 C atoms (type 3) on top. After reading in that dump file and relaxing the system for 100 steps, the ids are messed up. Already in the dump.0 file of the minimisation run, the last lines now read

6238 2 18.049 52.3421 27.8434 1.3061e-05 -2.71416e-05 3.70348e-05 0
6239 2 21.6588 52.3421 27.8434 9.21725e-06 -8.52306e-05 4.23204e-05 0
6240 2 25.2686 52.3421 27.8434 -1.82207e-05 -5.39465e-05 3.94414e-05 0
6241 2 28.8784 52.3421 27.8434 -4.84774e-06 -1.11829e-05 3.55877e-05 0
6242 2 32.4882 52.3421 27.8434 3.93298e-06 -1.05465e-05 3.56603e-05 0
6243 2 36.098 52.3421 27.8434 1.76612e-05 -6.45678e-05 5.30987e-05 0
6244 2 39.7078 52.3421 27.8434 -1.76819e-06 -8.94564e-05 5.29035e-05 0
6245 2 43.3176 52.3421 27.8434 -1.36654e-05 -2.14203e-05 4.38947e-05 0
6246 3 22.5 9 28.5 32.8193 -0.853612 24.3748 0
6247 3 7 27 28.5 -57.6578 -19.0446 170.477 0
6248 3 39 27 28.5 -46.1588 -4.40136 38.7045 0
6249 3 22.5 45 28.5 31.7346 -4.11137 23.4582 0

while those other C atoms now have ids from 3121 to 3125. So ids do seem to get hussled about. This is where my original question came from: how to tell the read_dump command to read (and thus hopefully preserve) the ids and types with the help of the label keyword? Annoyingly, even with the manual at hand, I do seem to keep doing something wrong and lammps keeps spitting out my job with an illegal read_dump error.

If you can suggest to me how to make lammps read and preseve ids and types from the dump file (either through the proper use of the label keyword or whatever else), then I should be all ok.

Kind regards,
Peter

7

Peter - can you post a simple input script with your read_dump and
the dump file (smaller is better) that is giving the problem you describe?

Looks like this is a bug if the atom IDs are getting messed up.
That will help me debug.

Steve

8

Hi Steve,

I've posted an archive with input and output files at

http://dutsm2227.tudelft.net/testfiles.tar.gz

It uses the COMB3 interaction, not part of the standard distribution. If you don't have that one on your system, then substituting any other interaction model in its place would probably be fine. The id number shuffling is already present in the dumpfile produced at t = 0, so if you make it any totally unrealistic system that explodes in the simulation, that would presumably not make a difference for any suspected bug really being present or not.

greets,
Peter

9

Hi Axel,

Thanks for your reply. The reason I was trying to use dump text files is that they can be made to be written at start, intermediate stages and end, without needing to convert from binary files. Not that conversion from binaries is a big effort, what you suggest works perfectly fine of course (very tiny thing is that the restart command doesn't have an accompanying option like dump_modify to sort the output according to atom id, right?). But having only one text file format involved from beginning to end does seem very practical. The lammps manual says that write_data functionality will be extended (at the moment there really is no way to make it produce files periodically, right?). Once that is done, that should give me what for my work seems the ideal practical scenario.

a) what is it about sorting the files by atom id that is so important,
same for having to read them back in text format?
b) you can probably have write data been executed as part of an
"every" option to the run command. and if that doesn't work, you can
still build a loop manually, since what the "every" option does is
effectively a shortcut for that.

Until then, at the risk of seeming stubborn, it seems dump files should offer me the option I'm looking for. From what Steve wrote, I understand now that reading charge was never going to work. But id and type should. And it seems that's all that is missing for me right now. If I start from a dump file reading in just x, y and z with the input line

read_dump dump-start 0 x y z add yes

the atom ids get messed up. In my initial dump file (not reading any structure file through read_data), the last few lines of my system are

what do you mean my "not reading any structure through read_data"? and
why do you need the "add yes"?
are you trying to "abuse" the read_dump command as a replacement for
read_data? then you get what you are asking for.

6238 2 39.7078 52.3421 27.8434 8.27188e-08 -5.25299e-07 -0.000139169 0.0132712
6239 2 45.1225 50.5372 27.8434 1.75151e-08 1.98775e-06 -0.000139557 0.0153997
6240 2 43.3176 52.3421 27.8434 1.38936e-06 -4.92382e-07 -0.000138153 0.0137494
6241 3 7 9 28.5 -58.4792 -6.96921 174.279 0
6242 3 22.5 9 28.5 32.7348 -0.851364 24.3077 0
6243 3 39 9 28.5 -46.608 -1.48362 39.1276 0
6244 3 7 27 28.5 -57.5051 -18.9934 170.027 0
6245 3 22.5 27 28.5 32.3661 -2.5265 23.9976 0
6246 3 39 27 28.5 -46.0426 -4.38918 38.5888 0
6247 3 7 45 28.5 -55.3075 -30.132 162.928 0
6248 3 22.5 45 28.5 31.6533 -4.10018 23.3929 0
6249 3 39 45 28.5 -44.9383 -7.11559 37.5379 0

The system is 6240 Cu atoms (type 2) that form a substrate, 9 C atoms (type 3) on top. After reading in that dump file and relaxing the system for 100 steps, the ids are messed up. Already in the dump.0 file of the minimisation run, the last lines now read

6238 2 18.049 52.3421 27.8434 1.3061e-05 -2.71416e-05 3.70348e-05 0
6239 2 21.6588 52.3421 27.8434 9.21725e-06 -8.52306e-05 4.23204e-05 0
6240 2 25.2686 52.3421 27.8434 -1.82207e-05 -5.39465e-05 3.94414e-05 0
6241 2 28.8784 52.3421 27.8434 -4.84774e-06 -1.11829e-05 3.55877e-05 0
6242 2 32.4882 52.3421 27.8434 3.93298e-06 -1.05465e-05 3.56603e-05 0
6243 2 36.098 52.3421 27.8434 1.76612e-05 -6.45678e-05 5.30987e-05 0
6244 2 39.7078 52.3421 27.8434 -1.76819e-06 -8.94564e-05 5.29035e-05 0
6245 2 43.3176 52.3421 27.8434 -1.36654e-05 -2.14203e-05 4.38947e-05 0
6246 3 22.5 9 28.5 32.8193 -0.853612 24.3748 0
6247 3 7 27 28.5 -57.6578 -19.0446 170.477 0
6248 3 39 27 28.5 -46.1588 -4.40136 38.7045 0
6249 3 22.5 45 28.5 31.7346 -4.11137 23.4582 0

while those other C atoms now have ids from 3121 to 3125. So ids do seem to get hussled about. This is where my original question came from: how to tell the read_dump command to read (and thus hopefully preserve) the ids and types with the help of the label keyword?

lammps already uses the IDs to identify existing atoms and then
updates their information.

Annoyingly, even with the manual at hand, I do seem to keep doing
something wrong and lammps keeps spitting out my job with an illegal
read_dump error.

If you can suggest to me how to make lammps read and preseve ids and types from the dump file (either through the proper use of the label keyword or whatever else), then I should be all ok.

use a matching data or restart file *first* and there should be no
problem. you seem to be skipping this. *why*?

axel.

10

ok, now I see what you are doing with the files you posted.

You are creating an empty simulation box, then populating
it with a read dump add.

When you “add” atoms from a dump snapshot that do not already exist,

LAMMPS does not preserve their atom IDs. Rather it assigns

new ones. This is b/c it doesn’t know whether the IDs conflict
with atoms already in the system. If you do this on one proc,

and they appear in sorted order in the dump file, you will likely
get back the same IDs. However if you do this on multiple
procs, then the atoms are assigned to different procs (based
on geometry), and when the IDs are reassigned, proc 0 will

get 1 to M1, proc 1 will get M1+1 to M2, etc. So they will
likely be different than in the dump file.

However, that shouldn’t matter. All the info from the dump
file is now in LAMMPS, and the simulation should run fine.
Assuming your script do something like put atoms in groups
based on their IDs, assuming they are the same IDs as in the dump file.

This “feature” is there, b/c the usual way to “add” atoms
from a dump file is to do it for atoms unrelated to the ones
already loaded into LAMMPS (e.g. from a data file).

So LAMMPS is trying to prevent duplicate IDs.

If you don’t want this re-assignment of IDs to occur, then you
should do as Axel suggested and define your atoms first
in the usual way (e.g. read the original data file), then read the
snapshot from the dump file, which will simply change
the coords of existing atoms, without changing any IDs.

Steve

11

Also, I just added a “q” field to read_dump so
you can read in charge values. I agree that
would be useful for a model with variable
charge like COMB potentials.

It will be in the next patch.

Steve