Beware, I've just realized that pmemd.cuda_SPFP in the master branch has a
bug that shows up in the constant pH routines (those results are bad).
DPFP is fine. I've determined what I think the problem--something I did
about two months ago with the intention of clarifying things, but I didn't
go far enough. It only shows up in the constant pH routines because things
are getting refreshed frequently, mixing situations where the intended
change takes effect and those where it does not.
The change was this: there is an array of float2 (two fp32s) called
pbAtomChargeSPLJID. That is, "atom charge (single precision) PLUS Lennard
Jones type index." It's good to couple these things for memory access
efficiency, but it's bad because at some point we end up representing an
integer as a float, then casting it back to an integer, to index into
another array (Lennard Jones parameter tables). This is quite safe for the
Lennard Jones typing--integers in the range +/- 2^23 can be represented
exactly by fp32. But it's the whole issue of INTENT in the way that array
is handled--I made it so that the charge was loaded as a float (no change),
but the LJID was loaded as a __uint_as_float(), then read back as a
__float_as_uint() to explicitly preserve the bitwise representation. (This
can also be done with unions.) Speed is not an issue for this case--the
conversion back to integer happens outside a loop where the real work gets
done.
But, before I fix this, I'd like to float (!) the question of what to do in
these situations. It looks clunky to explicitly load and unload an
unsigned int into the float2 data--but it serves as a reminder of what is
really happening and in some situations it will be faster.
Dave
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Oct 25 2017 - 10:30:02 PDT
