Re: [AMBER] GBSA speeds for big molecules

From: Daniel Roe <>
Date: Wed, 28 Jan 2015 08:15:40 -0700

In addition to what Carlos and Jason said, keep in mind that although
your total ns/day may be lower with GB, your effective sampling is
probably higher since there are fewer degrees of freedom and the
solvent viscosity is practically absent.


On Wed, Jan 28, 2015 at 8:08 AM, Carlos Simmerling
<> wrote:
> to add to what Jason said, we giving more info on timing for GB runs in
> Amber on GPUs in our recent article. Also, read this to see our suggestions
> for which GB model we suggest to use- you don't specify which one you
> tried.
> %A H. Nguyen
> %A J. Maier
> %A H. Huang
> %A V. Perrone
> %A C. Simmerling
> %T Folding Simulations for Proteins with Diverse Topologies Are Accessible
> in
> Days with a Physics-Based Force Field and Implicit Solvent
> %J J. Am. Chem. Soc.
> %V 136
> %P 13959-13962
> %D 2014
> On Tue, Jan 27, 2015 at 5:18 PM, Jason Swails <>
> wrote:
>> > On Jan 27, 2015, at 4:18 PM, Asmit Bhowmick <> wrote:
>> >
>> > Hello Amber users,
>> >
>> > I am trying to do an MD simulation of a big protein(~ 22,000 atoms) with
>> > Amber12 software. The 1st thing I tried was to use GBSA with Amberff99SB
>> > given the system size. However, the speeds I am getting are surprisingly
>> > slow. On 64 cores of an AMD opteron 6274 processor(2.2 Ghz) using PMEMD
>> and
>> > using 16 A cutoffs for both VdW and rgbmax, I get about 0.2 ns/day (~ 300
>> > ms/step). Are these the standard speeds to expect on such a big system
>> with
>> > GBSA ?
>> They are not surprising to me. Do you get nearly-linear scaling up to
>> these 64 cores? (This linear scaling really assumes either very good
>> interconnect between nodes or a 64-core node). If scaling is not very
>> good, then something weird might be happening (are you using pmemd.MPI
>> instead of pmemd? Does the output file state that 64 nodes are being
>> used?) However, even if your timings really are only making use of 1 CPU,
>> you will definitely not get better than 3.8 ns/day -- probably a decent bit
>> less (unless something that you’re doing is leading to resource thrashing
>> that renders the 64-thread performance *worse* than 1-thread performance,
>> which is possible).
>> That said, GBSA is a very poorly-scaling method -- it scales as O(N^2),
>> since it typically requires *very* large cutoffs (a 16 A GB cutoff is
>> probably too small). This is notably worse than PME, which, by virtue of
>> the FFT used in the reciprocal calculation, scales as O(N.logN). The only
>> reason GB is frequently faster is because PME usually requires a lot more
>> particles -- but there is a crossover point in which the algorithmic
>> advantages of PME outweigh the extra particles it requires over GB. That
>> cutoff is quite likely less than 22K atoms (but I’ve never simulated a
>> system that large).
>> Some more info here -- while technically using a cutoff reduces the
>> scaling of a simulation from O(N^2) to O(N), the lack of any pairlist or
>> spatial “cell” decomposition in the sander and pmemd GB code drops you back
>> to O(N^2) complexity. So while a 16 A cutoff is computationally cheaper
>> than no cutoff, it isn’t *that* much cheaper.
>> > Are there any suggested methods to simulate such a big protein ?
>> Check out the GB functionality in NAB (which you can actually use to run
>> MD). It is parallelized just like pmemd (although it is also parallelized
>> with OpenMP, which is likely a better choice if you are staying completely
>> within a single node), but it *does* use a pairlist and so probably runs a
>> little bit faster. There is also a new O(N.logN) GB scaling method in NAB
>> called the heirarchical charge partitioning scheme (HCP). I’ve never used
>> it myself, but it was designed for use with very large systems, and you may
>> find that it will substantially improve performance.
>> It does require some extra steps when preparing the system, which are
>> described in the manual.
>> Another thing to check out -- see what the GPU performance for your system
>> is. You may find that it is quite acceptable.
>> HTH,
>> Jason
>> --
>> Jason M. Swails
>> BioMaPS,
>> Rutgers University
>> Postdoctoral Researcher
>> _______________________________________________
>> AMBER mailing list
> _______________________________________________
> AMBER mailing list

Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 307
Salt Lake City, UT 84112-5820
(801) 587-9652
(801) 585-6208 (Fax)
AMBER mailing list
Received on Wed Jan 28 2015 - 07:30:03 PST
Custom Search