From: Axel Kohlmeyer (
Date: Tue Feb 04 2014 - 07:44:58 CST

On Tue, Feb 4, 2014 at 7:40 AM, Norman Geist
<> wrote:
> Hello people,
> just wanted to tell that I've found out what is so slow in sscache. It's the
> program call itself which is increasing for some reason the more memory VMD
> is using, in any case every "exec" takes about a second approximately just
> to start running STRIDE which usually finishes instantly. So the time spend
> by sscache is just waiting for TCL's "exec" to actually start the
> executable. I also checked if it has something to do with environment pathes
> etc but I guess the problem is lying deep in TCL. So I just changed the
> sscache code a little so it will write out a bunch of frame pdbs and call
> stride for all the pdbs in only one exec instance. Unfortunately I had also
> to implement the parsing of the output again.

hmm... if you go this far, why not go one step farther and write a
little wrapper that turns the "main()" call on stride into a tcl
command and then bypass the entire file writing, reading and parsing
procedure, but pass and return a TclList object as needed? the only
thing that would be worrying is that you would have to hunt down
memory leaks inside the stride code, as they would quickly accumulate
unlike with running an executable.

if i remember correctly, folks in TCBG are working on a new tool
inside of VMD that would work similarly. john may be able to comment
on that.


> So for now I have a sscache implementation that is 100 to 1000 times faster,
> depending on SSCACHEBUNCH which is the global variable that controls the
> number of frames computed at once. So while playing the trajectory the 1st
> time, sscache will run few seconds for frame 0 and play smoothly the next
> If someone is interested I'd like to share the code. It's also compatible
> with REMD.
> Best wishes
> Norman Geist

Dr. Axel Kohlmeyer
College of Science & Technology, Temple University, Philadelphia PA, USA
International Centre for Theoretical Physics, Trieste. Italy.