VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_cmm.chem.upenn.edu)
Date: Tue Jul 14 2009 - 18:00:35 CDT

On Tue, 2009-07-14 at 23:31 +0100, Dan Lussier wrote:

dan,

> Thanks Axel. Just a couple of follow up questions:
>
> 1 - Would it be possible to fool the velocity parser into taking other
> values by switching other columns (i.e. atom-wise potential energy,
> coordination number) into the location identified by vx, vy, vz in the
> header?

yes, that should work. the parser will read the column header and
then assign corresponding columns in the dump to vx, vy, vz.

> 2 - If it isn't possible to get the other variables at load time is it
> possible to inject them, for lack of a better word, into the frame
> after the frames have been loaded by reading a column of a the ASCII
> file manually using Tcl? Along these lines is there a typical free
> user variable in VMD that can hold atom-wise values read in from files
> or calculated by Tcl?

yes, there are currently four.
http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/cpmd-vmd/part3.html#chap5_sect3
check out the script at the example linked to from the URL above.
this computes the deviation from an ideal sphere and then stores it
in the "user" field (which is per atom, per timestep) and then uses
the color by user scheme. the user field can also be otherwise used
in scripts and for computations. there is no big difference
between $sel get {x y} and $sel get {user user1}

> 3 - Would the situation be any better or different when using DCD dump
> files? From what I have gathered they only store the atom positions,
> so I would need to manually load even velocities if this is possible.

not at all. dcd only stores positions. the main advantage of dcd files
is that they are read much faster, since they need to text parsing
(which is very slow). i generally write to .dcd or .xtc for trajectories
in lammps and then use the print facility to generate a separate file
with the data i want to use in VMD for analysis. that can be read into
hash indexed by the frame number using repeated gets. however, i usually
don't have per atom properties, but rather per group or per system...

i think, if you can get away with hacking the code to produce fields
that are recognized as vx, vy, vz and then stored by the molfile reader,
you probably have the fastest solution.

the long term goal is to have a (mostly) binary format that is
extensible, fast to read and then make all optional fields available
in VMD without having to use any script hacks, which are often too slow.

cheers,
   axel.

> Thanks again,
>
> Dan
>
> On 13-Jul-09, at 8:21 PM, Axel Kohlmeyer wrote:
>
> > On Mon, 2009-07-13 at 19:44 +0100, Dan Lussier wrote:
> >
> > dan,
> >
> >> I had a question about using other data beyond just x,y,z from LAMMPS
> >> ascii files produced by 'dump custom ...' command.
> >
> >
> >> As it stands I am loading the LAMMPS ascii dump files using a loop
> >> over a list of files like:
> >>
> >> set x 0
> >> foreach filename [glob $search] {
> >> set file_num [scan $filename "$filespec%d"]
> >>
> >> if { ($file_num >= $ilo) && ($file_num <= $ihi)} {
> >> puts "Processing: $filename ($x)"
> >>
> >> if {$x == 0} {
> >> mol new $filename type lammpstrj
> >> set mol_name $filename
> >> } else {
> >> mol addfile $filename type lammpstrj
> >> }
> >> incr x
> >> }
> >> }
> >>
> >> This does a good job loading the system's geometry but as expected
> >> leaves out the other values from the dump file.
> >>
> >> I'm interested in loading data from other columns of the dump files
> >> (i.e. atom-wise potential energy, atom-wise coordination number,
> >> etc.)
> >> and was hoping there was a VMD friendly way to do this either as the
> >> files are loaded or after the fact by looping over the frames.
> >
> > sorry, but as of the very latest version of the LAMMPS plugin in VMD,
> > you can only retrieve the information about atom velocities.
> >
> > for everything else, the corresponding APIs are not yet available
> > in the molfile plugin interface. the LAMMPS plugin parser does
> > recognize a lot of entries, but has no way to pass this on.
> >
> > plans to adjust the API to have additional (and at some point
> > arbitrary) properties passed along are underway, but will have
> > to wait until after the release of 1.8.7 and then will need to
> > be implemented on a case by case basis depending on demand,
> > usefulness and ease of implementation.
> >
> > since for the increasing likelihood of multimillion particle
> > simulations and the impracticality to do lots of analysis in
> > postprocessing, i expect the demand and usefulness to increase
> > steeply over the next couple of years...
> > our group will definitely have demand along those lines.
> >
> > cheers,
> > axel.
> >> Any advice would be great.
> >>
> >> Many thanks.
> >>
> >> Dan
> >
> > --
> > =
> > ======================================================================
> > Axel Kohlmeyer akohlmey_at_cmm.chem.upenn.edu http://
> > www.cmm.upenn.edu
> > Center for Molecular Modeling -- University of Pennsylvania
> > Department of Chemistry, 231 S.34th Street, Philadelphia, PA
> > 19104-6323
> > tel: 1-215-898-1582, fax: 1-215-573-6233, office-tel: 1-215-898-5425
> > =
> > ======================================================================
> > If you make something idiot-proof, the universe creates a better
> > idiot.
> > 

-- 
=======================================================================
Axel Kohlmeyer   akohlmey_at_cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.