Re: [AMBER] NTT=3 or NTT=1

From: Jason Swails <jason.swails.gmail.com>
Date: Tue, 11 May 2010 23:28:39 -0400

On Tue, May 11, 2010 at 11:19 PM, Ross Walker <ross.rosswalker.co.uk> wrote:

> Hi Tom,
>
> > > you will get better performance if you are running in parallel
> > > using ntt=1 than you will using ntt=3 (without some undocumented
> > compile
> > > time 'hacks')
> >
> > Would you be able to elaborate on these hacks (and how they might
> > affect the results)? I've been running lots of ntt=3 and an
> > improvement in parallel scaling would be most welcome...
>
> This is only in AMBER 11 but could conceivably be back ported to AMBER 10
> if
> need be.
>
> Recompile both sander.MPI and pmemd.MPI with the following define in the
> config.h file:
>
> -DNO_NTT3_SYNC
>
> This turns off the use of a single random number generator when running
> with
> NTT=3. In order to ensure reproducibility across different processor counts
> the code uses the same random seed on all threads and steps through the
> random stream on all threads to ensure the random numbers are always used
> in
> the same order regardless of mpi thread count.
>
> If you set NO_NTT3_SYNC then the code just uses a different random seed on
> each thread and thus an independent random number stream (it assumes you
> are
> setting ig=-1 in the cntrl namelist). This removes a serial bottleneck from
> the code and gives better scaling at higher thread counts for ntt=3.
>
> The caveat is that the results will now be DIFFERENT for different thread
> counts since the random number streams will be different. Neither is any
> more wrong so it is perfectly reasonable to do this. It just means that ALL
> of the test cases involving ntt=3 will fail because the random number
> streams will no longer match. Hence why I term it a 'hack'. and why it is
> not documented. Hence you should build without the ifdef first, make sure
> everything passes in parallel and then rebuild with the ifdef.
>

Does this exist, and/or is it of any use in pmemd? It would seem as though
pmemd would be worth speeding up in this regard more (since it's the
'performance' end of amber). However, since the load balancer is far more
sophisticated in pmemd, I see the possibility that it may not help nearly as
much.

A quick grep shows that there's an ifdef NO_NTT3_SYNC and an ifndef
NO_NTT3_SYNC in the pmemd source directory. What's the verdict on this?

Thanks!
Jason


> I hope this helps.
>
> 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 | http://www.wmd-lab.org/ |
>
> 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
>



-- 
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Graduate Student
352-392-4032
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Tue May 11 2010 - 20:30:07 PDT
Custom Search