Re: [AMBER] RAM requirements

From: Dmitry Osolodkin <>
Date: Wed, 01 Jun 2011 20:36:07 +0400

Hi all again,

I've tried to make a solvated protein in tleap with the command
"solvatebox M TIP3PBOX 275" to start with rather simple test system. It
used 8 Gb RAM, then 7.5 Gb swap and hanged. It probably means that
solvatebox routine memory usage is not optimal.

Interestingly, GROMACS successfully built this system using only 6 Gb
RAM, but I'm not familiar with that program and its forcefields. The
resulting PDB file size is 1 Gb. Is it possible to convert it into AMBER
format or I need to solvate it from scratch?

Best regards,

On 05/28/2011 03:09 AM, Robert Duke wrote:
> Hi Dmitry,
> I am not sure what changes were made in the amber 11 code; I am fairly
> familiar with the code base through 10, as I pretty much wrote the bulk of
> it. As of Amber 10, the code only handled 999,999 atoms, due to some file
> format limitations. I recollect that was changed in 11; I had even
> advocated it be changed earlier. I really had to move onto other things
> past amber 10, as my funding to work on amber died. Anyway, I am assuming
> you may well need to be building a 64 bit executable for the types of atom
> counts your are dealing with, but would have to look at a few things to be
> sure (I am on the road at the moment, without any source around). One thing
> that happens is total collection of all data in the master, which means that
> the memory requirement could get out of hand at really high atom count. If
> you all are really going to run 10-20 million atoms (sorry, don't remember
> exactly what you said), I would start trying no more than 256 nodes, and see
> what happens (so aside from the master, that would be like running less than
> 100,000 atoms per node, which is generally very tractable for pmemd). I
> would then scale up, say adding 128 nodes per trial, and see when other
> factors start giving you grief. One would expect a lot of the performance
> to scale with atom count, but not everything will, so there will be some
> performance issues for sure (like building a structure called the CIT).
> There are some very large data distribution problems I fear you will hit
> also, based on my (currently fuzzy) detailed knowledge of how various things
> are done. I would be interested to hear about your problems and may be able
> to make a few other suggestions. These are interesting and solvable
> algorithm issues; fixing them just did not get funded. If I were you I
> would also look at scaling up my problem more slowly than jumping from 1
> million to 20 million atoms all at once - you have a better chance of seeing
> the performance problems coming up, rather than just getting hammered by a
> system that is either crashing or running extremely slowly.
> Best wishes - Bob Duke
> -----Original Message-----
> From: Dmitry Osolodkin []
> Sent: Friday, May 27, 2011 11:01 AM
> To: AMBER Mailing List
> Subject: Re: [AMBER] RAM requirements
> Dear Bob,
> Thank you for detailed responce.
> On 05/27/2011 07:05 PM, Robert Duke wrote:
>> You are talking about some really big system sizes here; I am guessing you
>> would want to start with 128 nodes or more (non gpu code metric here; I
>> really don't know about the gpu code - sorry to say).
> We will definitely not use GPU code. Our first task is to make a
> requirements specification for a supercomputer possible to perform such
> simulation, especially RAM per CPU requirements. We'll start with large
> number of nodes, but not extremely large -- maybe 1024. Are there any
> recommendations about reasonable atom per CPU ratio? Do they depend on
> the system size?
> All the best,
> Dmitry.
>> Best wishes - Bob Duke
>> (bottom line - the memory numbers at startup from the master are at best a
>> wild and low guess, due to the adaptive nature of the code)
>> -----Original Message-----
>> From: Jason Swails []
>> Sent: Thursday, May 26, 2011 9:01 PM
>> To: AMBER Mailing List
>> Subject: Re: [AMBER] RAM requirements
>> I think pmemd outputs the number of allocated integers and floating point
>> numbers allocated for each simulation, so run a 0-step minimization and
> look
>> for those numbers.
>> Note that each thread, I believe, allocates about the same amount of
> memory
>> (a little bit more) than the only thread of a serial pmemd job. It has
> some
>> atom-ownership maps in addition to the normal data structures, but that's
>> ~1/3 the size of just the coordinate, velocity, force, and old velocity
>> arrays (which leaves a relatively small imprint).
>> HTH,
>> Jason
>> On Thu, May 26, 2011 at 5:08 PM, Dmitry Osolodkin
>> <>wrote:
>>> Dear AMBER developers,
>>> we are going to perform a MD simulation for an extremely huge system
>>> (ca. 10 millions atoms, maybe twice more). How to calculate memory
>>> requirements per processor for such task? We'll probably use pmemd.
>>> Thanks in advance
>>> Dmitry
>>> --
>>> Dmitry Osolodkin.
>>> _______________________________________________
>>> AMBER mailing list

Dmitry Osolodkin
Group of Computational Molecular Design
Department of Chemistry
Moscow State University
Moscow 119991 Russia
Phone: +7-495-9393557
Fax: +7-495-9390290
AMBER mailing list
Received on Wed Jun 01 2011 - 10:00:05 PDT
Custom Search