VMD-L Mailing List

From: Jérôme Hénin (jhenin_at_ifr88.cnrs-mrs.fr)
Date: Tue Aug 31 2010 - 10:38:49 CDT

John,

Whether VMD keeps using Stride or switches to a different program or
implementation, my understanding is that per-timestep storage of SS
will be needed anyway, right?

About Stride itself: I don't know of a better algorithm at this point.
Optimizing the current implementation would require an extended
license agreement in any case[1], so I suppose it would ideally be
done in collaboration with the authors (at least Prof. Frishman).

If the licensing issue cannot be sorted out, then re-implementing from
scratch will be the only way. I'd offer to contribute, but anything
CUDA-related is beyond my coding abilities.

Cheers,
Jerome

[1] The Stride license does allow for modifying the code, but its
contains a copyleft-style restriction ("viral" copyright) and a
non-commercial-only provision, both of which conflict - as far as I
understand - with VMD's permissive license.

On 30 August 2010 18:57, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> Jerome,
>  It would be relatively easy to teach VMD to store per-timestep
> secondary structure data so that one wouldn't have to use the sscache
> script.  I haven't put any effort into doing this, in part because I'd
> been hoping to come up with a better tool for SS determination than
> STRIDE.  Beyond the single-threading limitation that the current
> version of STRIDE has, it also has various issues with
> very large structures, structures that are far from the origin, and
> it often doesn't behave well with minor variations in atom naming
> conventions.
>
> My thought has been that rather than running multiple instances of STRIDE
> in parallel, it might be time to begin a project to rewrite STRIDE itself,
> and address not only the performance issue that you're experiencing, but
> also some of the other problems I described above.  Even better would
> be to make a GPU accelerated version of STRIDE, applicable to very large
> structures where even a multi-core CPU version would leave a lot to be
> desired in terms of performance.
>
> I haven't taken any action on rewriting STRIDE as I haven't been able
> to justify spending the time yet, but every month that goes by, it becomes
> a bigger issue, so it may soon be time to deal with it whether it is
> convenient or not.
>
> If a small group of people wanted to undertake the work collectively,
> that would almost certainly be the best way to go about getting it done.
>
> Cheers,
>  John
>
>
> On Mon, Aug 30, 2010 at 06:28:45PM +0200, Jérôme Hénin wrote:
>> Hi all,
>>
>> The current system VMD uses for protein secondary structure
>> assignment, while it works, has shortcomings. One is performance: when
>> dealing with large trajectories, the initial assignment performed by
>> the sscache script is fairly slow. One idea would be to take advantage
>> of multicore machines by running stride on multiple frames at once.
>> The issue here is that VMD itself knows only one secondary structure
>> assignment per molecule - right now that's handled fully in Tcl by
>> scache. After a quick look at threads in Tcl, I've decided that it
>> might not be a good idea to parallelize on that side. So it seems that
>> as long as VMD does not have secondary structure as per-timestep data,
>> we're stuck.
>>
>> Another idea is to avoid writing to disk the data fed to Stride -
>> either using named pipes, or requesting from the authors the
>> permission to link Stride into VMD. I am not sure how much performance
>> would be gained by doing this though - it could be that disk caching
>> reduces the performance impact of the current implementation to almost
>> zero.
>>
>> I'm sure others have been thinking about this for a while, so I'd like
>> to hear your perspective. I can name at least two people who are going
>> to answer this :-)
>>
>> Cheers,
>> Jerome
>>
>>
>> PS: unsubscribe vmd-l. Seriously guys. And namd-l too. I mean it.
>
> --
> NIH Resource for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> Email: johns_at_ks.uiuc.edu                 Phone: 217-244-3349
>  WWW: http://www.ks.uiuc.edu/~johns/      Fax: 217-244-6078
>