[lammps-users] ERROR: Atom IDs must be consecutive for dump xyz

LAMMPS LAMMPS Mailing List Mirror
1

Dear LAMMPS authors and experts,
I've just started using your wonderful program on a regular basis and
I got a question.

I'm doing "fix deposit" with airebo potential and nve + langevin,
writng down the snapshots of the run via "dump all xyz".

Somewhere along the way, after ~500k time steps, the program chokes
producing the
"ERROR: Atom IDs must be consecutive for dump xyz"

As the manual explains, it is because "dump all xyz" requires atom sorting,
and "dump_modify sort" option is turned ON,
while, for some reason,
the program fails to produce consecutive atom IDs for output.

I searched this mailing list archive for an answer and found a suggestion
to use the native lammps dump instead of xyz, as the former one does
not require
sorting and "consecutive IDs".

However, I do prefer to preserve all xyz output, because now I
process my data via
VMD and Axel Kohlmeyer's VMD plugin "topotools", which is conveniently
able to read the
xyz snapshots with the variable number of atoms.

my question is: how to avoid this error, and why this error has been
produced in the first place?
Sorting failed? Or some atom ID's disappeared? I do not do any "fix
evaporate", though ...

Might this be a program bug, or I'm doing something wrong?

Thanks a lot in advance for any suggestions, Maxim

P.S. I'm using LAMMPS version 10Sep2010 (Update 18Oct10) on 32x to 64x
processors typically and
the tail of my output looks like this:

2

dear maxim,

Dear LAMMPS authors and experts,
I've just started using your wonderful program on a regular basis and
I got a question.

I'm doing "fix deposit" with airebo potential and nve + langevin,
writng down the snapshots of the run via "dump all xyz".

Somewhere along the way, after ~500k time steps, the program chokes
producing the
"ERROR: Atom IDs must be consecutive for dump xyz"

As the manual explains, it is because "dump all xyz" requires atom sorting,
and "dump_modify sort" option is turned ON,
while, for some reason,
the program fails to produce consecutive atom IDs for output.

i don't think xyz dumps really require sorting. for the all group
they did not. can you try to use "dump_modify <id> sort off"?

axel.

3

i don't think xyz dumps really require sorting. for the all group
they did not. can you try to use "dump_modify <id> sort off"?

Dear Axel, thank you for the suggestion, I'm trying to play with these
switches right now,
but it takes some time, because this is one of those nasty errors that
arrive
after a few thousand seconds of computation only :).
Based on another suggestion, I suspect also that something might have
happened to my atoms
(some might have disappeared ???) because of bad insertions via
fix-deposit (too much overlap etc..)

In the error log it says :
Segmentation fault (11) [bro114:03079] Signal code: Address not mapped

while I have no idea of the exact meaning of this, this may suggest that
some variable went seriously out of bounds?

Best egards, Maxim

4

i don't think xyz dumps really require sorting. for the all group
they did not. can you try to use "dump_modify <id> sort off"?

Dear Axel, thank you for the suggestion, I'm trying to play with these
switches right now,
but it takes some time, because this is one of those nasty errors that
arrive
after a few thousand seconds of computation only :).
Based on another suggestion, I suspect also that something might have
happened to my atoms
(some might have disappeared ???) because of bad insertions via
fix-deposit (too much overlap etc..)

indeed. it could be that the sort error is a symptom
and that avoiding it will not removed the cause.

you may be running out of memory for neighbor lists?

In the error log it says :
Segmentation fault (11) [bro114:03079] Signal code: Address not mapped

if you compile with -g and enable core dumps (ulimit -c unlimited)
you can investigate with a debugger, where the seg fault is coming from.

axel.

5

Hey Maxim,
Is there any reason you can’t take a restart file from just before the error happens and try again with different dump settings? Since fix deposit is only psuedorandom, I think you should end up with a the same deposition and a nearly identical trajectory, and you should be able to reproduce the error. That’ll save you some computation time!

You can also dump every timestep when you’re so close to the error so that if it’s an overlapping particle problem, you’ll be able to see exactly what’s flying where in VMD. (If that does turn out to be the case and you can’t see what’s flying because your system’s too big, let me know and I can send you a python script using dump.py that I use to identify when particles get too close.)

Tyler

6

Thanks a lot, Tyler, indeed it looks like I need to do all that
stuff you describe.

Dump.py makes a part of pizza.py package, right?
I'm trying to learn it too. How does it compare, in terms of powerfulness
to simply writing processing scripts in VMD/tcl (that's what I'm
doing now).
Does it offer some diffucult-to-write stuff?
Also I see it uses some python packages that are quite old.
Which version of python should one install for it, 2.xx or 3.xx (windows 7)?

Best regards, Maxim

7

Dear Axel, Tyler and anyone interested.

Here you go, I do have lost atoms in my simulations.

ERROR: Lost atoms: original 1269 current 1268

Searching this archive further, I see that it is quite popular topic here -
lost atoms in conjunction with airebo potential either at high T or
(as in my case)
with an atom insertion gone bad.

now looking for more details ...

thanks again for your help

Regards, Maxim

8

Dump sorting has been reworked in the most current version.

"ERROR: Atom IDs must be consecutive for dump xyz"

This error message no longer exists in the current code.
So I would try that. But if you are losing atoms (and you want
to lose atoms), then you should set thermo_modify lost ignore.

Steve

9

Dear Steve, thank you for the explanations,
that would do it, I'll just switch to the most current code.
I do not want to lose atoms at present, while I do lose them, but this
is a
separate issue of airebo potential at small interatomic separations.
BTW, there was a recent bug fix for airebo in lammps in late Oct,
could it affect how the airebo is loosing atoms?

Best regards, Maxim

10

Hey Maxim,

Dump.py makes a part of pizza.py package, right?
I’m trying to learn it too. How does it compare, in terms of powerfulness
to simply writing processing scripts in VMD/tcl (that’s what I’mdoing now).
One significant difference is dump.py can handle any arbitrary trajectory column, whether it’s one of the more specific dump custom arguments like eradius, or a number you generate yourself, like position deviation from a specified frame, whereas VMD’s lammps trajectory plugin only reads in a small number of columns and tosses out the rest. I also can’t seem to figure out how to access some of the simplest trajectory information in tcl that I know VMD reads in, like timestep, but that could well be my ineptitude. So if you think you’d need to do anything out of the ordinary with a trajectory, dump.py might be the tool to use.
Does it offer some diffucult-to-write stuff?
Take a look at the documentation to see if it’s got anything built in that you’ve been painstakingly scripting in tcl.

On the other hand, the plus of doing analysis in VMD is that you’ve got the result immediately accessible for visualization.

Which version of python should one install for it, 2.xx or 3.xx (windows 7)?
Python 2.6.X is working fine for me with pizza.py.

Tyler

11

tyler,

Hey Maxim,

Dump.py makes a part of pizza.py package, right?
I'm trying to learn it too. How does it compare, in terms of
powerfulness
to simply writing processing scripts in VMD/tcl (that's what I'mdoing
now).

One significant difference is dump.py can handle any arbitrary trajectory
column, whether it's one of the more specific dump custom arguments like
eradius, or a number you generate yourself, like position deviation from a
specified frame, whereas VMD's lammps trajectory plugin only reads in a
small number of columns and tosses out the rest. I also can't seem to figure

actually, the molfile plugin itself can handle a large variety of columns,
however the plugin API currently allows to pass only coordinates, cell
information and velocities to VMD for further use.

there is an (undocumented) environment variable, LAMMPSREMAPFIELDS
that you can use to alias some properties to others. e.g.
using LAMMPSREMAPFIELDS=vx=fx,vy=fy,vz=fz would map the three force columns
to the three velocity columns.

out how to access some of the simplest trajectory information in tcl that I
know VMD reads in, like timestep, but that could well be my ineptitude. So

the timestep number is not stored. VMD just reads frames.

axel.

12

BTW, there was a recent bug fix for airebo in lammps in late Oct,
could it affect how the airebo is loosing atoms?

Doubtful, but you can try it out.

Steve

13

Hey Maxim,
You’ve probably solved the problem right now, but in case not, I just realized how useful vmd’s trajectory->velocity coloring method is for identifying flying atoms. If you’re dumping velocities, the flying atoms will stand out immediately.
Tyler