Thanks for the detailed answer, Bob.
All makes sense. I'll look into the specifics of our arrangement with
the service provider and try to set up pmemd. As for the number of
nodes, I'm going to run some benchmarks before any production
simulation. That should answer the question about the optimal number of
threads that should be involved.
Thanks again
Sasha
Robert Duke wrote:
> PMEMD generally won't scale well to 1024 running processors currently,
> BUT you can generally use a smaller number and get more done than with
> namd at the same processor count. I don't know the exact current
> comparison - depends on run conditions, machine, problem size, how
> many processors you use, how many processors per node you use, etc.
> etc. But we do pretty darn well, all considered, and we do the amber
> ff absolutely correctly at full precision. Ross has put benchmarks
> for the current release (10) on the ambermd.org website - a good thing
> to look at to get an idea of what you can get (uses up to 512 cpu on
> bigger problems; actual allocated cpu's may be higher for max
> production but this is less efficient). I still have benchmarks for
> the pmemd 9 release out there on a broader spectrum of machines; pmemd
> 10 is say roughly 20-50% faster, topend, for a number of different
> setups than pmemd 9; one of the complexities in comparison is that a
> lot of machines have actually gotten slower between the 9 and 10
> release (so take topsail here at unc - they doubled the processor
> count moving to clovertown processors, but that decreased available
> interconnect bandwidth per processor and the cpu clock rate was also
> dropped to about 2/3 of what it was (so now you need 3 cpu's to get
> the same compute power you had with 2). So ask yourself, do you want
> to be able to claim that you are running on 1024 cpu's, or do you want
> to get the number of nsec you need for your simulation with minimal
> impact on your cpu allocation? Overall, I have been avoiding doing a
> bunch of comparative benchmarks because 1) it takes lots of time, 2)
> there are all sorts of apples and oranges problems with the benchmarks
> (possible exception is JAC, but it is small and also competitors
> change run conditions, accuracy, etc), and 3) folks tend to get upset
> with each other over results in the competing camps about unfair
> comparisons and wild claims.
> Regards - Bob Duke
>
> ----- Original Message ----- From: "Sasha Buzko" <obuzko.ucla.edu>
> To: "AMBER Mailing List" <amber.ambermd.org>
> Sent: Tuesday, March 03, 2009 9:55 PM
> Subject: Re: [AMBER] A good way to use an Amber force field with NAMD?
>
>
>> Thanks, Ross.
>> Actually, I like this idea. Regarding scaling, though: do you know
>> how well PMEMD scales on over 1024 processors compared to NAMD? I
>> keep hearing that NAMD is considerably faster at these cpu numbers..
>> If the scaling is comparable, I'd certainly try to do a local install
>> (and could use your help in that case).
>> Thanks again
>>
>> Sasha
>>
>>
>> Ross Walker wrote:
>>>> to answer your question about the requirement: we are trying to get
>>>> some
>>>> supercomputer time, and they only have NAMD installed. In any event,
>>>> it's not our choice.
>>>>
>>>
>>> Just a quick question. Why not just install AMBER yourself. It
>>> builds on
>>> every supercomputer I have ever used without issues. You can install
>>> it in
>>> your home directory as well.
>>>
>>> To be honest even if I planned to use NAMD I'd do this. It can be
>>> pretty
>>> brave to use the supercomputer center installed version unless you
>>> implicitly trust the person who installed it.
>>>
>>> If you let me know what machine it is I can probably install AMBER
>>> for you
>>> (or give you a suitable config file to use).
>>>
>>> All the best
>>> Ross
>>>
>>>
>>> /\
>>> \/
>>> |\oss Walker
>>>
>>> | Assistant Research Professor |
>>> | San Diego Supercomputer Center |
>>> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk | |
>>> http://www.rosswalker.co.uk | PGP Key available on request |
>>>
>>> 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
>>
>
>
> _______________________________________________
> 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 Fri Mar 06 2009 - 01:12:19 PST
