From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Tue Oct 26 2010 - 09:43:48 CDT

dear aric,

please always keep the mailing list in cc:, so that people that
may run into a similar problem can search the list archives and
find the solution.

On Tue, Oct 26, 2010 at 8:43 AM, Aric Newton <agnewton_at_berkeley.edu> wrote:
> Dear Axel,
> Thank you for your prompt reply.  I have gone through and updated TopoTools
> to v.1.1.  That has resolved one of the unstated issues associated with
> importing the structure i.e. v.1.0 did not support the topo
> guessatom command I was trying to use to assign element names from their
> masses.

ok. yes. also i expanded that functionality only recently.

> With regard to the second plugin update, I have downloaded the latest
> vmd-lammpsplugin from the link you provided and the test file does seem to
> compile (first batch of output below: no errors, just warnings) and the file
> lammpsplugin.x.dSYM is created.  But, the actual make for the plugin reports
> an error (second set of terminal output).  I am compiling the plugin on a
> MacBook running OS X 10.5.8.  I used Spotlight to try to find
> crt1.10.5.o and found it in the directory
> /Developer/SDKs/MacOSX10.5.sdk/usr/lib.  This is a part of the directory
> tree I don't get to very often.  I am unsure of how to modify the makefile
> to resolve this conflict.  Any suggestions from you would be greatly
> appreciated.

i will have a look. it is a pity that macos is increasingly diverging from
what other unixiod platforms are doing. for a while

> I attempted to load the lammps trajectory data into the new structure
> imported using TopoTools v.1.1 and saved as a *.psf file, but the resultant
> animation (line art) remains the same. Will I need to re-order the atoms by
> index no. for each timestep in the lammps trajectory?  With regard to the

the new plugin should take care of it. i'll see if i can send you are
precompiled binary of the plugin somehow.

> Materials Studio data files I am having  trouble with, I have uploaded the
> *.car, *.mdf, and *.lammps05 files (file base name Na_MMT_hyd_vsMD.*) that
> describe the model structure to the BioCoRE Help (Public) /testfiles/
>  directory.

thanks. got them. the perfect place would have been the VMD (Public) project,
but you are not the first person to mix this up. it _is_ a bit
confusing to people
not used to dealing with biocore. i already found a horrible bug in
the mdf plugin
that will cause a buffer overflow and could explain the issues you are seeing.
it won't help with the reading of the lammps trajectory.

unless you have a working version of the new lammps plugin, you might
consider using the dcd or xtc file format to output your trajectories in lammps.
those will reorder the atoms before writing and will also need less disk space
and read _much_ faster. the only drawback of those formats is, that they cannot
store the additional fields that the lammps custom dump format allows.

more later,
    axel.

> Thank you for assisting me with this.
> Aric
>
> aric-macbook-3:vmd-lammpsplugin agnewton$ make test
> gcc  -o lammpsplugin.x -DTEST_PLUGIN -O2 -Wall -W -fno-strict-aliasing
>  -D_USE_ZLIB -g lammpsplugin.c -lm  -lz
> lammpsplugin.c: In function ‘open_lammps_read’:
> lammpsplugin.c:325: warning: unused parameter ‘filetype’
> lammpsplugin.c: In function ‘open_lammps_write’:
> lammpsplugin.c:1082: warning: unused parameter ‘filetype’
> lammpsplugin.c: In function ‘write_lammps_structure’:
> lammpsplugin.c:1102: warning: unused parameter ‘optflags’
> lammpsplugin.c: In function ‘read_lammps_timestep’:
> lammpsplugin.c:792: warning: ‘ylen’ may be used uninitialized in this
> function
> lammpsplugin.c: At top level:
> hash.c:183: warning: ‘hash_delete’ defined but not used
> hash.c:270: warning: ‘hash_stats’ defined but not used
> inthash.c:182: warning: ‘inthash_delete’ defined but not used
> inthash.c:269: warning: ‘inthash_stats’ defined but not used
> aric-macbook-3:vmd-lammpsplugin agnewton$ ls
> Makefile inthash.c lammpsplugin.x.dSYM vmdconio.h
> README inthash.h largefiles.h vmdplugin.h
> hash.c lammpsplugin.c molfile_plugin.h
> hash.h lammpsplugin.x periodic_table.h
> aric-macbook-3:vmd-lammpsplugin agnewton$
>
> aric-macbook-3:vmd-lammpsplugin agnewton$ make
> gcc  -shared -fPIC -O2 -Wall -W -fno-strict-aliasing  -D_USE_ZLIB -g -o
> lammpsplugin.so -I. lammpsplugin.c  -lm  -lz
> lammpsplugin.c: In function ‘open_lammps_read’:
> lammpsplugin.c:325: warning: unused parameter ‘filetype’
> lammpsplugin.c: In function ‘open_lammps_write’:
> lammpsplugin.c:1082: warning: unused parameter ‘filetype’
> lammpsplugin.c: In function ‘write_lammps_structure’:
> lammpsplugin.c:1102: warning: unused parameter ‘optflags’
> lammpsplugin.c: In function ‘read_lammps_timestep’:
> lammpsplugin.c:792: warning: ‘ylen’ may be used uninitialized in this
> function
> lammpsplugin.c: At top level:
> hash.c:183: warning: ‘hash_delete’ defined but not used
> hash.c:270: warning: ‘hash_stats’ defined but not used
> inthash.c:182: warning: ‘inthash_delete’ defined but not used
> inthash.c:269: warning: ‘inthash_stats’ defined but not used
> Undefined symbols:
>   "_main", referenced from:
>       start in crt1.10.5.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [lammpsplugin.so] Error 1
> .
> On Oct 25, 2010, at 7:02 AM, Axel Kohlmeyer wrote:
>
> On Sun, 2010-10-24 at 08:45 +0900, Aric Newton wrote:
>
> vmd-l users,
>
>
> aric,
>
> Approach 1
>
> Referring to archived posts (Wednesday, August 11 2010; Volume 01 :
>
> Number 1657), I attempted to load first the *.mdf (structure) and then
>
> *.car (coordinate) files from Materials Studio.  When loading the
>
> *.mdf file, I get an error due to the "namelist index value being too
>
> large" (message reproduced below) and the process is aborted.  Is
>
> there away to set the "larger index types" when compiling VMD?  The
>
> any changes like this would have to be made to the source
> code to the molfile plugin that reads .mdf files.
>
> if you can upload the problematic file(s) to the VMD biofs
> into the testfiles directory, somebody can take a look at
> it. other than that, you are on your own. the plugin refers
> to mdf specifications from 1998 as documentation, so perhaps
> your file has features that confuse that VMD plugin.
>
> the same goes for the .xsd format, which will most likely
> require writing a new plugin, which in turn requires a
> reasonable documentation and a selection of example files
> as well as a person with the ability to program such a
> plugin and the time and interest to do it.
>
> [...]
>
>
> Approach 2
>
> Using the TopoTools plugin, I loaded the initial data file for my
>
> LAMMPS simulations with the readlammpsdata <filename> command.  The
>
> structure was imported accurately, but when I load the trajectory data
>
> into the structure and animate the trajectory, I get abstract art.
>
> Namely, from frame zero (imported structure) to one (trajectory), the
>
> model is rendered as random line art with a definitive x-y grid
>
> pattern of voids.   I presume that the atom indexes become mixed as a
>
> result of the way that LAMMPS keeps track of the atoms and dumps them
>
> to the trajectory which is not in order of the atom indexes but by
>
> processor (the voids in the abstract line art are from dividing the
>
> atoms by processors (?)).  Is my presumption accurate and is there a
>
> procedure I am overlooking when trying to merging LAMMPS data and
>
> trajectory files that solves this problem?
>
> these issues should have been corrected in the latest alpha
> test versions of VMD. unfortunately, there are currently only
> precompiled versions for linux and solaris.
>
> you can update your topotools plugin from here:
> http://sites.google.com/site/akohlmey/software/topotools
>
> and download an updated lammps molfile plugin source from here:
> http://sites.google.com/site/akohlmey/software/lammps-icms
>
> check out the attached archives. please let us know if you
> have problems compiling installing those.
>
> i'd be interested to see your files, if you still have
> problems with the updated plugins.
>
> cheers,
>    axel.
>
>
>
> Your advice and input is appreciated.
>
>
> Thank you,
>
>
> Aric
>
> --
> Dr. Axel Kohlmeyer  akohlmey_at_gmail.com
> http://sites.google.com/site/akohlmey/
>
> Institute for Computational Molecular Science
> Temple University, Philadelphia PA, USA.
>
>
>

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