VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Jun 01 2010 - 11:04:09 CDT

No problem, there are so many Tcl/Python entry points in VMD, I wouldn't
expect even an expert user to know them all. Even I don't have them all
memorized. ;-)

Cheers,
  John

On Sun, May 30, 2010 at 11:26:07AM +0200, Jérôme Hénin wrote:
> Thanks John, I really don't know how I managed to miss those Tcl procs.
>
> Jerome
>
> On 28 May 2010 05:16, John Stone <johns_at_ks.uiuc.edu> wrote:
> >
> > Jerome,
> >  Have you looked at whether you can use the existing "gettimestep"
> > and "rawtimestep" routines from by making Tcl eval calls from
> > your C++ code without needing to modify VMD itself?
> >
> > I suspect your problems were caused by hijacking internal program
> > state from an unsafe point during command processing, but without having
> > all of the code/patches I can't say for sure.
> >
> > I would start by looking at whether there's a reasonable way to use
> > gettimestep and rawtimestep and we can go from there.
> >
> > Cheers,
> >  John
> >
> > On Thu, May 27, 2010 at 02:27:00PM +0200, Jérôme Hénin wrote:
> >> Hi all,
> >>
> >> I have a VMD-hacking problem, which might be similar to what some of
> >> you have tried. We'd like to have Tcl-wrapped C++ code do some calculations
> >> efficiently, accessing VMD's atom coordinate data directly. Ideally,
> >> that would be dynamically loaded, and not require recompiling VMD.
> >>
> >> We have a python hack, where the python "timestep" routine (from
> >> py_numeric.C) is called to get a python array, from which one can
> >> extract the C pointer and work directly with it.
> >>
> >> There is an interestingly ugly Tcl variant where a small Tcl routine
> >> (added to TclCommands.C) gets the pointer (i.e.
> >> myMolecule->get_frame(myFrame)->pos), casts it to a long int and
> >> returns that. The integer is passed to my Tcl-C++ "plugin" (loaded
> >> from a shared object), which casts it back to (float *), and goes on
> >> to do the computation. This, on top of being ugly, requires inserting
> >> this little Tcl hook and recompiling VMD. Amazingly though,
> >> it works just fine.
> >>
> >> In yet another variant, I have tried to eliminate the middle-man and
> >> the need to modify and compile VMD by accessing VMD's internals
> >> directly from my dynamically loaded C++ code. This felt a bit dangerous:
> >> I was surprised that it worked up to a point, and then disappointed
> >> that it didn't work all the way. Here are a few relevant lines from that
> >> function:
> >>
> >> VMDApp *app = (VMDApp *)Tcl_GetAssocData(interp, (char *)"VMDApp", NULL);
> >> Molecule *mol = app->moleculeList->top();
> >> Timestep *ts = mol->get_frame(0);
> >>
> >> The result is the following: I do get a pointer to the top molecule,
> >> but calling methods from that object essentially give me garbage (e.g.
> >> the returned pointer from get_frame is off). I suppose that these are
> >> not supposed to be called from external, dynamically loaded code, but
> >> I don't understand all the details, for example, why the calls to
> >> VMDApp methods do give me the right answers.
> >>
> >> Could anyone point me to information that would help me understand
> >> this? Does anyone have an opinion on a better way to obtain this kind
> >> of "lightweight plugin" functionality?
> >>
> >> Thanks,
> >> Jerome
> >
> > --
> > 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
> > 

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