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.
-Dan
On Wed, Jan 28, 2015 at 8:08 AM, Carlos Simmerling
<carlos.simmerling.gmail.com> 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 <jason.swails.gmail.com>
> wrote:
>
>>
>> > On Jan 27, 2015, at 4:18 PM, Asmit Bhowmick <asmit.berkeley.edu> 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.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
>>
> _______________________________________________
> AMBER mailing list
> AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
--
-------------------------
Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 307
Salt Lake City, UT 84112-5820
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-6208 (Fax)
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jan 28 2015 - 07:30:03 PST
