Tuning does not effect results. Allowable tuning flags include
DIRFRC_*, SLOW_INDIRECTVEC, SLOW_NONBLOCKING_MPI (not recommended except for
really slow interconnects), FFTLOADBAL_2PROC (not really that helpful except
for small processor count workstations, sometimes). All the NEED_* and
BUILD_* defines are for internal use only, basically allowing code reuse in
places. DON'T define these... (basically if you see something #define'd in
the code itself, it is probably not a good idea to dink with it... - then
one exception I can think of being selecting the FFT library in use, and
that should all automate through the configure script). The stuff you can
mess with is really pretty much covered in the README. As for a new
architecture, I typically try the various permutations to see what works -
something like 12 of them if memory serves. There are basic differences
depending on risc vs cisc, and how much support there is for vector
operations for the cpu. One can guess by looking at how a similar chip is
being handled; turning on DIRFRC_EFS is a pretty good idea for intel
ia32-like chips (not necessarily itanium, I don't recall).
Regards - Bob Duke
----- Original Message -----
From: "Thomas Zeiser" <thomas.zeiser.rrze.uni-erlangen.de>
To: <amber.ambermd.org>
Sent: Wednesday, April 21, 2010 4:12 PM
Subject: [AMBER] effect of pre-processor flags on pmemd?
> Dear Amber experts,
>
> in our present procurement, we are asking the vendors to give
> commitments for the Amber performance in their answers to our RFP.
> The selected benchmark case is the standard "NPT cellulose"
> testcase and they are expected to run the benchmark on 32+ nodes,
> thus, with a considerably high number of MPI processes.
>
> One vendor is now asking what pre-processor flags they are allowed
> to use for compiling pmemd10 (the patch level is up to the vendors
> as they have to get the sources and a benchmark license
> themselves):
>
> | I assume that it is allowed to set -DDIRFRC_NOVEC and
> | -DSLOWINDIRECT_VEC, hence these invoke only different
> | implementations of the same physics.
> |
> | But what about parameters that effect the physics itself like
> | -DDIRFRC_EFS, -DDIRFRC_COMTRANS, -DNEED_ENE, -DNEED_VIR, and
> | -DBUILD_PAIRS_CALC_xxx?
>
> Coming from the compute center, I'm not an expert for the internals
> of Amber and only some the defines mentioned above are listed in
> the PMEMD README (DIRFRC_NOVEC, SLOWINDIRECT_VEC, DIRFRC_COMTRANS
> while the remaining ones seem to be used internally all the time).
>
> Thus, I'd appreciate any comments on what we should allow the
> vendors (and what the impact of allowing/disallowing a certain flag
> has on the "general usability for a wide range of input files").
> Tuning for a certain hardware is fine but the tuning should not
> influence the results from the chemical point of view.
>
>
> Thanks,
>
> --
> Dr.-Ing. Thomas Zeiser, HPC Services
> Friedrich-Alexander-Universitaet Erlangen-Nuernberg
> Regionales Rechenzentrum Erlangen (RRZE)
> Martensstrasse 1, 91058 Erlangen, Germany
> http://www.rrze.uni-erlangen.de/hpc/
>
> _______________________________________________
> 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 Wed Apr 21 2010 - 14:00:05 PDT
