VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Tue Feb 04 2014 - 10:13:51 CST

Norman,
  I'm sure people will find your script helpful both in the mean time,
until we have a new SS code ready for VMD, and also your script is a
good example solution the performance issues that arise with 'exec'
for VMD (or any similar) processes that use a large amount of physical
memory which causes exec to get progressively slower. Even after we
have replaced STRIDE with a new faster SS algorithm, others may find your
approach and description of the performance issue very helpful.
If you can send me your code along with a little documentation,
I'll get it posted soon.

Cheers,
  John Stone
  vmd_at_ks.uiuc.edu

On Tue, Feb 04, 2014 at 05:01:29PM +0100, Norman Geist wrote:
> Hi John,
>
> I will just submit the changed script to you, have a look at it and decide
> if people could use a "linux only" but for now incredibly faster version of
> sscache to be available as download, until your new algorithm is ready.
>
> Norman Geist.
>
>
> > -----Ursprngliche Nachricht-----
> > Von: John Stone [mailto:johns_at_ks.uiuc.edu]
> > Gesendet: Dienstag, 4. Februar 2014 16:01
> > An: Axel Kohlmeyer
> > Cc: Norman Geist; VMD Mailing List
> > Betreff: Re: vmd-l: SScache performance; fast secondary structure
> > assignment
> >
> > 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/ 

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