VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_cmm.chem.upenn.edu)
Date: Thu May 24 2007 - 08:19:04 CDT

On Wed, 23 May 2007, Yinglong Miao wrote:

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

the plugin was writting in plain c (this has the least complications)
and i sent you the sources so you can have a look.

as peter mentioned, using swig can be much easier.

YM> I know what I want to do is not specific to vmd, but I want to make use
YM> of the functions which have been included in VMD, like mol, atomselect,
YM> writedcd, etc. There is a package called "Ftcl" available for

you have to realize, that using TCL from within a plugin can
make things a lot more complicated and error prone. if you can
give us an overview of the kind of analysis that you have in mind,
and particularly the flow of data, perhaps we may be able to
give a recommendation on how to structure it so you reduce
complications.

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

my suggestion on how to approach this would to start with writing
the framework completely in tcl, and then add the compute routines
as tcl prototypes (using a minimal test problem). once you have
identified, where you actually lose the most time, you can think
about how to make it faster by replacing tcl constructs with
subroutines from a plugin. in my experience, the most time is frequently
lost on using an inefficient algorithm (or implementation thereof),
and that cannot be solved by using a compiled language.

as to how to embed plugins and how to autoload them, please consult
one of the tcl textbooks.

as to how to link VMD to lapack, we should perhaps discuss a little
bit more in detail, as i have been thinking of interfacing (some of)
lapack to VMD for quite a while now, as there are several operations
that would benefit from it a lot. particularly when operating on large
systems. interfacing scalapack i would avoid, since you then need to
interface MPI (or equivalent) as well, and that would open yet another
(large) can of worms. since several LAPACK/BLAS implementations are
multi-threaded, it would probably be sufficient (for a while)
to just use an SMP/multi-core machine and the integrated threading.

also, depending on how much information needs to go back and forth
and how 'interactive' your analysis is going to be, just using
VMD/tcl to preprocess data, run a standalong executable on it and
postprocess its output with VMD/tcl again, can still be a very
efficient and viable alternative.

cheers,
   axel.

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

-- 
=======================================================================
Axel Kohlmeyer   akohlmey_at_cmm.chem.upenn.edu   http://www.cmm.upenn.edu
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
=======================================================================
If you make something idiot-proof, the universe creates a better idiot.