VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Feb 04 2014 - 09:00:55 CST

Hi,
  Axel's suggestion is a good one, but I would be very worried about
having STRIDE running as part of the main VMD process as it is not
bulletproof in my experience. We have been working on a new
secondary structure assignment that we hope will eliminate the
need for STRIDE. Our new program eliminates several bad design points
in the original STRIDE code that are responsible for algorithms that have
quadratic time complexity. Our new SS code is not ready yet, but I am hoping
that it will become part of VMD in a couple more months. When our SS code
is finished, I expect it will be MUCH faster than STRIDE in all respects.
As soon as we have something that other people can test, I will let
people know.

Cheers,
  John

On Tue, Feb 04, 2014 at 08:44:58AM -0500, Axel Kohlmeyer wrote:
> 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. 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/