VMD-L Mailing List

From: jgrime_at_uchicago.edu
Date: Thu Sep 29 2011 - 09:49:32 CDT

Hi Axel,

I've been trying to map the velocity fields into VMD's "user" fields, so I can animate the trajectory using rendering based on my custom data (added in postprocessing to velocity fields in the LAMMPS trajectory). I've never used TCL before, and I ended up with this - which I run after loading the trajectory:

set framecount [molinfo top get numframes]
set sel [atomselect top all]

for {set frame_no 0} {$frame_no<$framecount} {incr frame_no} {
        animate goto $frame_no
        $sel frame $frame_no

        puts "$frame_no ..."

        foreach v [$sel get {vx vy vz}] {
                $sel set user [lindex $v 0]
                $sel set user2 [lindex $v 1]
                $sel set user3 [lindex $v 2]
        }
}

... and I think I'm nearly there, but it's still not working: the same values seem to appear in the user fields for each frame in the trajectory. I'm guessing that it simply copies over all the previous data with whatever was in the last trajectory frame processed, as so I end up with all frames having the same data as present in the last frame. Doubtless I've done something stupid here, and I was wondering if you could help?

I also took a look at the webpage you sent, regarding the "molfile" plugin, which mentions the "LAMMPSREMAPFIELDS" environment variable. This variable would seem to do the job, but I'm not sure how to use it; would I have to write a TCL script which sets this variable, and then load the trajectory via the TCL script for these mappings to take effect? That seems like it would be a simple 3-line script using the "topo" command namespace, but I've not been able to get it to work.

Also, does the remapping in the "molfile" plugin use TCL to perform this mapping? The little script I wrote above seems very slow, which is to be expected I suppose as it uses TCL to interface with the VMD data. Is there a "native code" interface alternative, which I assume could be a lot faster?

Cheers,

John.

---- Original message ----
>Date: Wed, 28 Sep 2011 20:27:16 -0400
>From: owner-vmd-l_at_ks.uiuc.edu (on behalf of Axel Kohlmeyer <akohlmey_at_gmail.com>)
>Subject: Re: vmd-l: VMD with LAMMPS trjaectory - help?
>To: jgrime_at_uchicago.edu
>Cc: vmd-l_at_ks.uiuc.edu
>
>hi john,
>
>
>On Wed, Sep 28, 2011 at 7:20 PM, <jgrime_at_uchicago.edu> wrote:
>> Hi all,
>>
>> I'm visualising LAMMPS trajectories using VMD 1.9.
>>
>> The data I wish to visualise is a little odd, in the sense that it changes in an slightly unorthodox way; the number of atoms, and the "type" of the atoms, can change during the simulation.
>
>> I discovered that VMD has problems with trajectories where the number of atoms can differ between frames, and I got around this by estimating an upper bound of the number of atoms which would be present. I then postprocess to effectively add a "buffer region" at the end of each frame to allow for expansion and contraction of the system. This seems to work okay, but my current problem occurs when the number of atoms is fixed throughout the simulation:
>
>> I have not been able to discover a way to make VMD recognise certain changes over the course of the trajectory. I tell LAMMPS to write out the atom serial, molecule id, atom type and coordinates for each frame with the data sorted on the atom serial. I've tried reflecting the changes in the system by changing both the molecule id and the atom type for visualisation (ie I postprocess the "real" trajectory, and write an altered version for visualisation purposes), and VMD seems to simply use whatever information was present in the first frame of whatever trajectory it loaded.
>
>yes. that is by design. this massively reduces the amount of memory that
>VMD consumes for the - by far more common - case of this information
>not changing over the course of a trajectory.
>
>> I've verified this behaviour by writing single and multiple trajectory frames (before and after the changes occur), and when I deal with individual frames the data appears as I intended; where multiple frames are present, VMD does not reflect any changes in the system via altering the molecule id and/or atom type over the course of the trajectory.
>>
>> Is there a way to make VMD reflect such changes during a trajectory, and not simply use the data present in the initial trajectory frame? If this is not possible with a LAMMPS-style trajectory, is there a VMD-compatible trajectory format which does support such "dynamic" changes?
>
>there are two options.
>VMD currently only supports additional per frame information in the
>x-,y-, and z-velocity component and the LAMMPS plugins supports this.
>via remapping you can direct any property into one of those three
>fields. see:
>http://sites.google.com/site/akohlmey/software/lammps-icms#TOC-VMD-molfile-plugin
>you can then make selections based on the vx,vy, or vz value
>or use them for colorization or first copy them into one of the
>user fields.
>
>this still requires all frames to be of the same size.
>
>the second option is to read a variable size .xyz trajectory through
>the topotools plugin.
>this does the "buffering" automatically, and you can reflect whatever
>change you want
>in the atom name. the drawback of this approach is that it - for
>efficiency reasons -
>does not preserve the order of atoms and thus does not work for
>systems with bonds
>(you can still try using VDW in combination with DynamicBonds). see:
>http://sites.google.com/site/akohlmey/software/topotools/topotools---documentation#TOC-readvarxyz-file-name-
>
>HTH,
> axel.
>
>> Thanks,
>>
>> John.
>>
>
>
>
>--
>Dr. Axel Kohlmeyer
>akohlmey_at_gmail.com  http://goo.gl/1wk0
>
>Institute for Computational Molecular Science
>Temple University, Philadelphia PA, USA.
>