From: Yinglong Miao (
Date: Wed May 23 2007 - 22:20:39 CDT

Thanks for Axel's and Peter's suggestions!

For the "gofr" plugin Axel mentioned, which language did you use to
develop and compile the extension? I'd like to take a look at the
code/scripts and see how you implement it as a VMD plugin.

I know what I want to do is not specific to vmd, but I want to make use
of the functions which have been included in VMD, like mol, atomselect,
writedcd, etc. There is a package called "Ftcl" available for
interpreting TCL scripts in Fortran and creating Fortran extensions to
TCL. I made it work to calling TCL procs in Fortran but have problems
with figuring out how to construct Fortran extensions and call the
subroutine in TCL as commands.

So one possible way for my intention is that I can interpret TCL
scripts in Fortran except those procs which need intensive
computations. And one advantage for this is that I can link my Fortran
program to LAPACK/ScaLAPACK for better performance. But the problem is
that Ftcl seems to work only for basic TCL scripts and I don't know how
to make commands like mol, atomselect (those I mentioned above) work
for basic TCL interpreter (say tclsh8.4) without using VMD interpreter.
Like for a TCL script calling mol, atomselect and writedcd, which
plugins should I pick up and how to set environmental variables to work
with "tclsh8.4 myscript.tcl" and no need to use "vmd -dispdev text -e
myscript.tcl". Do you have any clue about this?

Thanks again for patience and again any more suggestions are greatly


Quoting Peter Freddolino <>:

> To add on to Axel's advice, one specific and relatively easy way of
> calling C/C++ code from Tcl is to use swig ( to
> create a wrapper; this is, for example, the approach used for the
> autopsf plugin. This is one of those "not specific to vmd" techniques;
> you can use it from any tcl program (or, for that matter, several other
> scripting languages).
> Best,
> Peter
> Axel Kohlmeyer wrote:
>> On Wed, 23 May 2007, Yinglong Miao wrote:
>> YM> Dear VMD developers/users,
>> dear long,
>> YM> I have been reading online VMD Plugin Programmer's Guide, but still
>> YM> have not find answers for my specific problem. I want to write a TCL
>> YM> package as a plugin to VMD, while in the TCL package script, I want to
>> YM> call Fortran/C subroutines for the core procedures, which are very
>> YM> computationally intensive. So can I develop an efficient Fortran
>> YM> program and archive it into a binary library file with those
>> YM> computation subroutines so that I can them in TCL scripts? If yes, how
>> the way you do it, is mostly not VMD specific, but more
>> a generic extension of the TCL interpreter. so it may be
>> useful to look at how you do this in the general TCL
>> literature (online or hardcopy).
>> what you propose is doable, how easy it is depends a lot on
>> what you want to input into the plugin and how generic it is
>> and/or whether you need and access to VMD internal data.
>> there are several plugins in the VMD plugin library, that
>> use compiled extensions to the VMD interpreter. if you need
>> a simpler example, i can also send you my first version of the
>> measure gofr command, which was implemented as a plugin.
>> if possible, i would recommend to avoid writing plugins in
>> Fortran or C++ (c++ is usally ok, if you avoid the STL based
>> parts of the c++ runtime. i.e. write c with classes),
>> so you don't have to deal with loading the appropriate runtime
>> library (which may be incompatible to what VMD was compiled with).
>> YM> to include a binary library in a TCL package? Or can anyone tell me
>> YM> other ways to call Fortran/C subroutines in TCL to speed up the
>> YM> calculation?
>> the alternative would be to hook up your functionality directly
>> into VMD (e.g. as an additional measure subcommand), but that
>> requirest that you recompile VMD for your purposes.
>> another option would be that you write your data to a file and
>> then call a separate program (SURF, STRIDE, and MSMS for example
>> are used like this) and read in the resulting output. whether
>> this is more convenient or efficient depends a lot on the kind
>> of analysis that you have in mind and how much data you are
>> shuffling around.
>> cheers,
>> axel.
>> YM>
>> YM> Any suggestios will be greatly appreciated.
>> YM>
>> YM> Best regards,
>> YM> Long
>> YM>
>> YM> --
>> YM> Yinglong Miao
>> YM> Ph.D. Candidate
>> YM> Center for Cell and Virus Theory
>> YM> Department of Chemistry, C203A
>> YM> Indiana University
>> YM> 800 E. Kirkwood Ave.
>> YM> Bloomington, Indiana 47405
>> YM> 1-812-856-0981 (office)
>> YM> 1-812-857-6205 (home)
>> YM>
>> YM>

Yinglong Miao
Ph.D. Candidate
Center for Cell and Virus Theory
Department of Chemistry, C203A
Indiana University
800 E. Kirkwood Ave.
Bloomington, Indiana 47405
1-812-856-0981 (office)
1-812-857-6205 (home)