VMD-L Mailing List

From: Jérôme Hénin (jhenin_at_ifr88.cnrs-mrs.fr)
Date: Thu Jun 03 2010 - 07:56:51 CDT

Hi John and others,

I finally had a chance to check out gettimestep and rawtimestep. These
create new Tcl byte array objects, which means that timestep data is
memcpy'd, unlike the equivalent Python routines, which provide direct
access to VMD's timestep data. This makes perfect sense from a Tcl
perspective, because you couldn't manipulate the C array directly in
Tcl anyway. But what I am trying to do is just to pass a pointer to a
C++ routine, so those Tcl hooks doesn't do the job for me.

Just in case, I am attaching the code for my failed attempt at getting
to the timestep data directly from my Tcl-wrapped C routine. To try
it, set the VMD directories in the Makefile, compile the so file. Then
load some structure into vmd, type "load carray.so", and "c_array" to
start the proc. It prints a bunch of pointers, which match VMD's
internal data structures... up to a point.

Any ideas are welcome.

Cheers,
Jerome

On 1 June 2010 18:04, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> 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
>