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.
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
Received on Tue May 11 2010 - 20:30:05 PDT
