From: Dan Lussier (dtlussier_at_gmail.com)
Date: Thu Jul 16 2009 - 04:46:03 CDT

Thanks Axel - I'll give your suggestions a try. Cheers.

Dan

On 15-Jul-09, at 12:00 AM, Axel Kohlmeyer wrote:

> 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.
>