VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Fri Jul 16 2004 - 10:31:22 CDT

Hi Olaf,

1) Yes, the .vmdrc is read _after_ command line args
   are evaluated, which makes this case slightly problematic currently.
   As you've discovered though, it is easy to copy your plugin into the
   system directory. I'm planning to standardize a nicer way for VMD
   to "discover" plugins in the User's home directory without having
   to modify .vmdrc, but we may have to adopt a strategy like having
   VMD search for a ".vmd" directory which could contain user's plugins,
   various VMD preference settings (cleaner than .vmdrc hacks people
   have had to do up until now) and related stuff. I'd have to come up
   with a similar strategy on Windows which is always painful, but that
   would probably work well for the Unix versions of VMD.

2) In cases where the various files you want to load are
   so closely inter-related that it is difficult or impossible
   to read them independently from each other, you can always write
   your plugin so that it loads multiple files at once. None of the
   existing VMD plugins work this way, but there's nothing preventing
   you from doing it. Worst case, you could make a new "index file"
   that lists the other files you need to load. You'd make your plugin
   register itself for this new "index file" and then it'd read the
   index file, and subsequently read and process the listed data files.
   
   This suggestion above may or may not even be necessary depending on
   how many different files you have to read and whether you can determine
   their filenames a priori. If you just have a single file that contains
   all of the various data, you can have the plugin register callbacks
   for all of the different data types. Plugins can completely parse
   files into their own internal data structures before they let VMD
   call the various callbacks by doing more of their work in their
   open_xxx_read() routines. 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...

  John Stone
  vmd_at_ks.uiuc.edu

On Fri, Jul 16, 2004 at 04:40:33PM +0200, Olaf Lenz wrote:
> Hello once more!
>
> I've written a simple file reader plugin to read data files of my
> coarse-grained simulations. During this process, I came up with a few
> issues.
>
> 1. I provide the file reader plugin "olplugin" (that contains a plugin for
> the file type "olmov") in my user directory. It is read in ".vmdrc" via a
> "vmd_plugin_scandirectory" command (Is this command documented in the
> manual? I have found it only on the mailing list.).
>
> I can use it when loading a molecule interactively from the GUI. However,
> when I try to use the plugin from the command line via
>
> vmd -olmov system.par
>
> I get:
> ---------
> Info) VMD for LINUX, version 1.8.2 (December 4, 2003)
> Info) http://www.ks.uiuc.edu/Research/vmd/
> [clip]
> Info) File loading in progress, please wait.
> ERROR) Cannot read file of type olmov
> ERROR) Loading of startup molecule files aborted.
> Found 4 plugins or data handlers in directory
> '/home/schmid/olenz/software.Linux/lib/vmd/plugins/molfile'.
> ---------
>
> When I provide the plugin in the system plugin directory, the command works.
> Apparently, ".vmdrc" is read after the file argument is evaluated.
>
> 2. To explain this, I need to give an example: I'm simulating a protein
> (i.e. a cylinder in my case) in a lipid bilayer. We're using a constant
> pressure MC simulation, that means that the system lengths fluctuate. The
> protein is placed at a fixed position relative to the system length (like
> 0.5*L_x, 0.5*L_y).
>
> I've written a structure file reader plugin that reads the structure of the
> system from the simulation parameter file. Among other things, the file
> contains the position of the protein relative to the system lengths.
> A data file reader plugin reads the lipid positions from the simulation
> data files for each timestep.
> Unfortunately, now the data file reader plugin has no possibility to
> determine the position of the protein, as this is given in the parameter
> file and not in the simulation data.
> As the system lengths changes in each timestep, the absolute position of
> the protein changes, too, therefore I can't simply create one fixed
> cylinder for the whole simulation.
>
> To solve this problem it should be possible to somehow transport some data
> from the structure file reader to the data file reader. Or is there another
> way?
>
> Olaf 

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