VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Sun May 23 2010 - 17:24:08 CDT

On Sun, May 23, 2010 at 5:46 AM, Moslem Sabouri
<sabouri.moslem_at_gmail.com> wrote:
> Hi,

hi!

> I have 2 problems with the "LAMMPS Trajectory" format in VMD.
> 1- In the code that I'm working on, the type of an atom can change during
> the simulation. for example the atom #100 which is of the type 1 in the
> first step, may change in type 2 in the step #500. But although the LAMMPS
> format takes the type of each atom in each step, it uses the type in first
> step for all slides. How can I use the types at each step for coloring the
> atoms?

you are running into a limitation of the VMD code, not the LAMMPS format.

> 2- Although this format contains the number of atoms for each step, I
> observed that change in the number of atoms in different steps causes an
> error in loading the trajectory file. How can I use this format for a
> variable number of atoms?

again this is a limitation of VMD. VMD is highly optimized to process
biomolecular simulations where the identity and number of atoms
does not change in the course of a trajectory.

> Finally, if these are not possible with LAMMPS format, could you please
> introduce a suitable format and a refrence in which different VMD formats be
> explaind?

it is not an issue of the file format, but rather of VMD itself.
handling data sets with a variable number of atoms and
varying atom properties is a tricky issue, if you do not want
to lose the good performance that VMD has for large data
sets (lots of atoms, lots of frames) where the number of atoms
and atom properties does not change.

most file formats that VMD supports are documented (or not) by
the respective package that writes these file formats natively.
there is some very incomplete documentation about formats at:
http://www.ks.uiuc.edu/Research/vmd/plugins/molfile/

coming back to your problem. the easiest way to deal with
flagging atom properties that change over time, is to store
them in one of the atom's user fields. those are currently
not directly available through the file format readers, but
need to be read in manually with a tcl script.

for the LAMMPS file format, there is a workaround by using
the vx vy or vz velocity fields, and they can be remapped
through an environment variable. since you seem to be
writing your file format natively, you can work around the
issue of a varying number of atoms by padding each frame
with dummy atoms. for reading .xyz format trajectory files i
have written a tcl based (i.e. slow for large systems and
long trajectories) molecule file reader that does this
upon reading. it then flags the visibility of an atom in
the "user" field, i.e. one has to change selections from
"all" to "user > 0". this version does not work well for
systems with bonds. you will need the latest version of
the plugin from here

http://sites.google.com/site/akohlmey/software/topotools

or use a recent alpha test version of VMD to be able
to try it out.

if your trajectory is not tool long, an alternative would be
to write each frame to a different file, load each of them
into a different molecule and then use the multimolanim
(and clonereps) plugin(s) to visualize and animate the
trajectory.

cheers,
    axel.
> Thanks in advance.
> M. Sabouri
> 

-- 
Dr. Axel Kohlmeyer    akohlmey_at_gmail.com
http://sites.google.com/site/akohlmey/
Institute for Computational Molecular Science
Temple University, Philadelphia PA, USA.