Re: Amber topology in CUDA NAMD - can it be done?

From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Tue Oct 19 2010 - 08:32:45 CDT

benjamin,

On Tue, Oct 19, 2010 at 8:27 AM, Benjamin Bouvier
<benjamin.bouvier_at_ibcp.fr> wrote:
> Hi all,
>
> Can the current CUDA NAMD implementation be used with an Amber topology?
> I've tried topologies for very different systems (with the latest CUDA-NAMD
> nightly) and systematically ended up with "CUDA-accelerated NAMD does not
> support NBFIX terms in parameter file". Is this inherent to NAMD's internal
> treatment of Amber topologies, or is there some kind of workaround?

none that i know. the NBFIX error is a bit of a misnomer.

if i am understanding the code correctly, the reason is the
following: for optimal performance, the GPU non-bonded
kernel stores the sigma and epsilon values for each
atom type in very fast memory on the GPU and then applies
the mixing while computing the pair interactions. this has
the advantage of needing only O(N) storage rather than O(N**2).

NBFIX refers to epsilon/sigma combinations for non-bonded
pair interactions that override the regular mixing rules. the error
message that you are seeing indicates that this override has
not been implemented yet. many codes implement this by
precomputing all epsilon/sigma pairs (or rather the C12 and
C6 coefficients and their derivatives) up front and then store
them in an array applying the overrides is done simply by
copying them over the precomputed mixed numbers.

now i don't know whether this is really required by amber
parameters or whether they are already stored in "pre-mixed"
form, so that it would be convenient to internally flag them a
NBFIX type parameters in NAMD. but obviously, the implementation
of NBFIX would require some programming and testing.

most likely, a second less efficient non-bonded GPU kernel
would need to be implemented that treats these exceptions
or stores the whole array of (pre-computed) parameter pairs
in a larger (but slower) location on the GPU. but this is just
my speculation.

> Sorry to bring the question up again -- I've seen a few similar queries on
> this list, but (AFAIK) none with a clear answer as to whether something can
> be done...

hope that explains this issue. perhaps jim has something
to add and/or correct.

cheers,
   axel.

> Thanks,
> --
> Benjamin Bouvier
>
>

-- 
Dr. Axel Kohlmeyer    akohlmey_at_gmail.com
http://sites.google.com/site/akohlmey/
Institute for Computational Molecular Science
Temple University, Philadelphia PA, USA.

This archive was generated by hypermail 2.1.6 : Wed Feb 29 2012 - 15:56:14 CST