On Wed, Jan 26, 2022, Dr. Anselm Horn wrote:
>
>I performed a quick test on that topic. Here is what I did.
An even quicker test is just to run a single point calculation, which shows
a big difference in dihedral energies, seemingly dependent on the sign of
the periodicity. If you change even one of the signs, except for the fifth
one), the dihedral energy changes.
Notes:
1. There are *two* "factor_ix" benchmarks, one in
$AMBERHOME/benchmarks/factor_ix, and one in the Amber20_Benchmark_Suite.tar.gz
file you can get from the GPU/benchmarks page at the Amber web site. The
latter has a formatted version of the prmtop file, and this is the one I
used.
2. The dihedral formula, cos(n*phi + delta) looks like it should be
independent of the sign of n when delta is 0 or pi (as it is here.)
3. I'm pretty sure the "culprit" here is the dihdup() routine (sander) or
the equivalent duplicate_dihedrals() routine (pmemd). This code is actually
changing the dihedral lists depending on the sign on n. There are even
comments in there about how n should never be negative, but somehow the code
persists. (This is a truly ancient part of amber, and represents
over-agressive optimization from back when computing speeds were measured in
Mflops.) My plate is really full today, so I don't have any more time to
explore this, but we should definitely put in a check for negative n values,
and probably better comment and refactor some of this truly old code.
4. My current bottom line is that the *timings* one gets from the factor_ix
benchmark (whcih only runs a few hundred steps) are probably fine, but that
no one should rely on the actual energies.
Thanks again to John Chodera and friends for finding and reporting this
problem.
....dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Wed Jan 26 2022 - 07:30:03 PST
