Re: [AMBER] pmemd.cuda and nonzero gbsa

From: Scott Le Grand <varelse2005.gmail.com>
Date: Tue, 4 Oct 2011 12:33:34 -0700

As someone who wrote a *really* fast SASA approximation 18 years ago
(basically Shrake and Rupley on steroids), here's my two cents.

The Still et al. approximation at the heart of GBSA has a correlation
coefficient of ~0.3 with the actual SASA. On the bright side, this
approximation has a derivative.

So if you're happy with some indeterminate analytic function of the number
of atoms surrounding a given atom as a surrogate for accurately calculating
the SASA, carry on... I'm not.

If someone provides an actual analytic SASA algorithm and recalculates the
GBSA coefficients to work with it, I'm happy to port it to the GPU (assuming
it doesn't do something boneheaded that makes a GPU implementation
impractical).

I remember pointing this out to someone who shall remain nameless at
Stanford (of all places) and I was informed that the Still et al. algorithm
is what *everyone* st Stanford uses (whatever their definition of *everyone*
was).



On Tue, Oct 4, 2011 at 11:43 AM, Ross Walker <ross.rosswalker.co.uk> wrote:

> Hi Nihal,
>
> > I am going to make free energy simulations of a protein via implicit
> > solvent
> > (igb=5) on GPU. My question is whether gbsa still not applicable on
> > pmemd.cuda. Is there a way to implement gbsa consideration while runing
> > on
> > GPUs? I have seen that a group from Stanford U. has managed to use such
> > a
> > combination (although on a different platform called folding.home, they
> > should have developed a "patch" themselves). Seeing that I wanted to
> > check
> > if there is any chance of applying gbsa+GPU combination.
>
> Unless someone wants to volunteer to write it there is currently no support
> for GBSA on GPUs. Right now we are focused on what I consider more
> important
> priorities given the GBSA approximation is pretty questionable at best.
> Scott Le Grand can chime in with his opinions on the subject here.
>
> I would suggest that your best approach is to run GB with pmemd.cuda with
> gbsa=0. Then when you come to do the MM-PBSA/GBSA calculations just run the
> single point energy calculations in sander with GBSA turned on - since it
> is
> only single point energies it will be very quick. If you have evidence that
> running the actual MD with GBSA turned on rather than just straight GB
> ultimately gives better binding energies than the MM-PBSA/GBSA post
> processing approach I'd be interested to read it.
>
> The other option is to go into the PMEMD code, remove the check for GBSA=0
> with cuda and then place GPU to CPU upload and download calls as
> appropriate
> around the CPU GBSA calculation code. This will suffer on performance
> though
> because of the continuous GPU/CPU synchronization going on.
>
> All the best
> Ross
>
> /\
> \/
> |\oss Walker
>
> ---------------------------------------------------------
> | Assistant Research Professor |
> | San Diego Supercomputer Center |
> | Adjunct Assistant Professor |
> | Dept. of Chemistry and Biochemistry |
> | University of California San Diego |
> | NVIDIA Fellow |
> | http://www.rosswalker.co.uk | http://www.wmd-lab.org/ |
> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> ---------------------------------------------------------
>
> Note: Electronic Mail is not secure, has no guarantee of delivery, may not
> be read every day, and should not be used for urgent or sensitive issues.
>
>
>
>
>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue Oct 04 2011 - 13:00:04 PDT
Custom Search