VMD-L Mailing List

From: Ajasja Ljubetič (ajasja.ljubetic_at_gmail.com)
Date: Tue Feb 04 2014 - 14:58:37 CST

Hi Norman!

Why not put the script(s) on github <https://github.com/> (or a similar
service)? It costs nothing, is simple to do and gives you a lot of
flexibility.

Regards,
Ajasja

PS: If you need some help with git/github, feel free to e-mail me off the
list.

On 4 February 2014 17:13, John Stone <johns_at_ks.uiuc.edu> wrote:

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