From: Norman Geist (norman.geist_at_uni-greifswald.de)
Date: Tue Feb 04 2014 - 08:00:29 CST

Hi Axel,

as I've heard of plans for a completely new and fast implementation of ss
visualization in VMD, I just don't wanted to spend too much effort in it.
But at the same time I was so annoyed of the current behavior and
performance of sscache and after some hacking around, I found an easy
solution without need to change VMDs source itself. It took only a few hours
for me to implement the changes and it runs reliable and very fast. When I
would had to wait about 20h for a 12 replica REMD each having 6000 frames to
cache the ss through, I now need only 1-2 min without doing anything
different in case of usage as with the original sscache. Moreover it uses
environment variables to find STRIDE and /tmp and so is quite clean to use.
Unfortunately it will only work on linux.

I hope people notice so I can share this huge improvement.

Norman Geist.

> -----Ursprüngliche Nachricht-----
> Von: Axel Kohlmeyer [mailto:akohlmey_at_gmail.com]
> Gesendet: Dienstag, 4. Februar 2014 14:45
> An: Norman Geist
> Cc: VMD Mailing List
> Betreff: Re: vmd-l: SScache performance; fast secondary structure
> assignment
>
> On Tue, Feb 4, 2014 at 7:40 AM, Norman Geist
> <norman.geist_at_uni-greifswald.de> 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.
>
> axel.
>
>
> >
> >
> >
> > 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
> > SSCACHEBUNCH frames.
> >
> >
> >
> > If someone is interested I'd like to share the code. It's also
> compatible
> > with REMD.
> >
> >
> >
> > Best wishes
> >
> >
> >
> > Norman Geist
>
>
>
> --
> Dr. Axel Kohlmeyer akohlmey_at_gmail.com http://goo.gl/1wk0
> College of Science & Technology, Temple University, Philadelphia PA,
> USA
> International Centre for Theoretical Physics, Trieste. Italy.