From: Marco Kalweit (
Date: Thu Oct 05 2006 - 10:06:25 CDT


we also have this behaviour when loading files, that have been dumped
from runs using more than one processor.
This was for a system with two metal blocks adjacent each other. When
running on two processors, the types of a part of one block was changed.

If I remember correctly then following this, I had a look at the dump
files and found that the types were messed up.
So I thought that this was a Lammps bug and did not care about it futher
at the moment.

The change you made will stop reading the file in as soon as it finds an
error. So I do not quite understand how it reads in correctly, following
a problem with the type or the id.


John Stone wrote:

> I'll have to take a look at this. The new version of the plugin
>included with VMD 1.8.5 contains a number of changes by Marco Kalweit
>which may relate to this, and so I'll have to look at it closely and
>see what's going on with the index field and get back to you.
>If you have a few LAMMPS trajectories you can post on the VMD public
>project on BioCoRE, that would be great. I have a bit of a shortage
>of LAMMPS test files, so the more files I have the better.
> John Stone
>On Tue, Oct 03, 2006 at 09:49:23AM -0700, Lutz Maibaum wrote:
>>yesterday I sent an email saying that the LAMMPS plugin might have a problem
>>reading dump files in which the atoms are not sorted by ascending atom-id.
>>Files of that form are generated when LAMMPS is running on more than one
>>I played around with the code for a little while, and for me the following
>>patch to the function read_lammps_structure in lammpsplugin.c (and
>>lammpspluginA.c) solves my problem:
>>< if ((atomid <= 0) || (atomid > data->numatoms))
>>< {
>>< fprintf(stderr, "lammpsplugin) Error while reading structure from
>>lammps dump file '%s': atomid %d is not in valid range [1,
>>%d]\n",data->file_name, atomid, data->numatoms);
>>< return MOLFILE_ERROR;
>>< }
>>< atom = atoms + atomid - 1;
>>> atom = atoms + i;
>>I believe that in this function the atom type was not assigned to the atom-id,
>>but just to an increasing index number. The above patch should fix that. I
>>don't know anything about the vmd code, so maybe someone could look over this
>>patch. If this works then the documentation should reflect the fact that the
>>LAMMPS plugin also conserves the atom types, and not just the positions.
>> Lutz