VMD-L Mailing List

From: Olaf Lenz (lenzo_at_mpip-mainz.mpg.de)
Date: Mon Nov 02 2009 - 14:57:49 CST

John Stone wrote:
> Given the capabilities
> of the current versions of Tcl, we can probably just delete this callback
> from the molfile plugin API since there are other ways to do this that
> closer to what Tcl wants anyway.

Yes, I would guess that is the case. It doesn't look as though
transferring data between the plugin's functions and Tcl functions is
planned, anyway, so I don't see the point in putting the Tcl functions
into the plugin.

> We are working on adding a new mechanism that will allow plugins to
> provide arbitrary "extra" data to VMD beyond the hard-coded fields
> defined by the existing molfile plugin interface. It will be accessible
> to scripting via Tcl/Python, and would not have the problems that global
> variables and the like would otherwise create. If you can tell me more
> about the kind of data that you intend to make available from your plugin,
> I can help you to implement it in your plugin using the new APIs I'm working
> on when they are ready.

The concrete example we're working on is the visualization of dipoles:
each "atom" is a particle that has a certain magnetic dipole with a
given direction. We would like, for example, to be able to visualize
this dipole by adding a small cone on top of the atom that shows the
direction of the dipole. In another project, these dipoles may even be
shifted with regard to the center of the atom.

However, as we often have the problem that we want to visualize
additional data, we would prefer it if we had a generic solution. So
far, I thought to do it like this:
We would extend the VTF format such, that each atom, bond, timestep and
even coordinate per atom could have arbitrary attached Tcl data (started
by the keyword "tcldata")

Example:
atom 1 name O tcldata red
atom 2 name N tcldata blue
timestep
1.0 2.0 3.0 tcldata 1.0 1.0 1.0
2.0 3.0 4.0 tcldata -1.0 -1.0 -1.0

This would signify a structure containing two "atoms", one having the
attached data "red" and the other "blue", which could be interpreted as
the color to be given to the dipole arrows, and one trajectory timestep,
where each coordinate also has an attached dipole moment.

The vtfplugin would read the structure and coordinates and ignore
everything after the "tcldata" keyword.
Furthermore, we would code a "vtftools" Tcl plugin, which would provide
a function to parse the tcldata from the file and read them into Tcl
arrays (by just "eval"uating everything after the tcldata keyword).

This would allow us and others in the future to have their simulation
program to write arbitrary data into the VTF format, to easily load it
from there, and to access it from VMD scripts, that then create
additional visualizations based on this data.

Of course, this would require us to parse the VTF format once with the
vtfplugin, and then again using the vtftools. If it would be possible to
  access the Tcl interpreter from the molfile reader plugin directly, we
could avoid this step and directly feed the data into the Tcl data space.

I think that this would be a possible way to go in the VMD molfile
plugin world in general: if the plugin's functions would have access to
the Tcl interpreter, they could easily modify everything within the Tcl
world based on data in the file.
I would even think that this would make it obsolete to think about a way
to provide extra data from the plugins, however at the cost that it
would not be easy to support Tcl and Python.

Best regards
        Olaf