VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Mon Jul 19 2004 - 10:07:45 CDT

Hi Olaf,

On Mon, Jul 19, 2004 at 01:14:29PM +0200, Olaf Lenz wrote:
> Hi!
>
> John Stone wrote:
> > As you've discovered though, it is easy to copy your plugin into the
> > system directory.
>
> It is, if you are root on the machine. Otherwise it isn't. I'd prefer if I
> would not need to install a personal plugin as root.

Agreed, but as I already mentioned, there's not presently a way for you to
force plugins to be loaded from anywhere outside the VMD installation directory
early enough in the startup process that you could use them from the command
line, which gets processed before .vmdrc currently. Once we have a standard
method for retreiving user's own personal plugins, this should not be a
problem.

> As for the second issue of the file reader plugins, I'd like to specify my
> problem more precisely.
[...]

I understand your problem, but there is presently no way for a plugin to
query VMD's internal data structures or derive information from data loaded
by other plugins. This is somewhat of a necessity as it compartmentalizes
the information that plugins need to know about and doesn't require the
addition of extensive interfaces for querying things back out of VMD.
The existing design for the plugin interface was based on our experience
working with the most common file formats used in molecular dynamics
simulations, there are bound to be file formats we haven't seen that
are organized differently, as yours are. Until you mentioned your problem
below, we hadn't any enountered file formats that contained incomplete
coordinate information in trajectory files. What program is generating
the data files that you're reading by the way?

I don't think there's any elegant way of giving a trajectory reader a
back-door into data previously read by a structure reader. There's no way
that the plugins can assume they correctly know which files went to which
molecules, the system just isn't designed to allow separate plugins to
exchange information like that amongst themselves or even with VMD.

Other than reading both files in a single plugin as you've already described,
there isn't (to my knowledge) any clean way to solve the problem you've
run into with the current source code. I'm willing to consider changing
how things work, but doing so breaks binary compatibility with the plugins
compiled over the last year, so it's only worth doing if I can make a well
thought out change that helps solve this problem without creating new ones.

Thanks,
  John Stone
  vmd_at_ks.uiuc.edu

> The whole issue is not a problem, when I have a single plugin that reads
> both the structure and coordinate files. For example. I've written a
> "movie" plugin that gets the system parameter file as argument and finds
> all the timestep coordinate files as they have a simple naming scheme, like
> "00100000.crd.gz" for timestep 100000.
>
> Sometimes, however, I'd like to read the system parameter file and a single
> timestep coordinate file that I'd like to choose by hand. Therefore I've
> split the plugin into two parts - a structure file reader plugin that reads
> the system parameter file, and a coordinate file reader that reads one
> timestep coordinate file (just like the "parm7" and "rst7" plugins do).
> The problem with this is, that I can't pass the internal data structure
> from the structure file reader to the coordinate file reader. This should
> normally not be a problem, as the coordinate file reader only needs to fill
> in the coordinates for the atoms. But in my system, I do have some atoms
> whose coordinates are not saved in the coordinate file, but which are fixed
> in the system and saved in the structure file. The question is now: how can
> I pass the coordinates of these atoms to the coordinate file reader.
> I can see two possible solutions:
>
> 1. I can parse the structure file once more when I read the coordinate
> file, just to derive the needed data. This is not very nice, as
> opening/parsing a file is relatively costly, and furthermore I'd need to be
> able to derive the parameter filename from the coordinate filename, or
> something.
>
> 2. I could use a global datastructure that is filled in by the structure
> plugin and read by the coordinate file plugin. Global datastructures are
> not really nice.
>
> Or is there another way?
>
> Olaf
>
>
> The gaussian cubeplugin reader is an
> > example of one that does a fair bit of calculation in the first
> > open_cube_read() call. At the limit, you could do all of the file
> > parsing work in the open_xxx_read() routine and have the structure,
> > bonds, volume data, and other callbacks merely copy out the data
> > the open_xxx_read() call has already processed. Most of the plugins
> > do some of the reading/parsin in open_xxx_read() and some later on,
> > but you're free to do it either way.
> >
> >Let me know if this explanation was helpful or not. I probably need
> >to add more text about all of this to the plugin writing docs... 

-- 
NIH Resource for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349              
  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078