> On Sun, May 27, 2012, Jason Swails wrote:
> >
> > Some words of warning: pmemd.cuda will ignore any off-diagonal
> > A/B coefficient changes. It recalculates sigma and epsilon and
> > recombines those when it calculates the Lennard Jones term for each
> > atom pair. Therefore, the only commands that will actually work for
> > pmemd.cuda are addLJType and changeLJSingleType (the changePair
> commands
> > will not work on GPUs).
>
> Ouch...let's make this a priority to get fixed. Does pmemd.cuda give
> the
> wrong answers without any warnings?
We have a bug filed for this already:
http://bugzilla.ambermd.org/show_bug.cgi?id=187
Unfortunately it is not likely to get fixed anytime soon because it will
need some MAJOR changes to the code. For now it needs someone (I suggest the
author of parmed which 'enabled' the bug to put in a check, or their
designated underling ;-).) Alternatively I'll add it to my todo list to add
the check myself but it will probably be a couple of months at the earliest
before I can get to it (NIH deadlines pending :-( ).
That said this sort of problem could potentially bite us in many places. The
intelligent designers never meant for the prmtop to be hacked with, look at
the original prmtop file format if anyone doesn't believe me. Thus those
that did were expected to consider such modifications to be a real research
issue and so would not be surprised if code did not behave as expected. Have
we ever actually properly supported off diagonal elements in the VDW terms?
- Certainly leap never supported it and the AMBER force field files don't
from what I am aware.
The issue now is that while hacking of prmtops etc used to be considered
expert we now have a tool that makes this routine. This is a MAJOR issue and
with it comes a substantial amount of testing that is now required to make
sure the various codes are compliant with the extra, untested, functionality
this is enabling. Are you certain that pmemd, sander (serial and parallel)
as well as NAB etc all work with the various hacks that can be done with
parmed? - Somebody needs to check this, by hand to verify they are correct
and then put in checks (and add documentation) for cases where the various
hacks are not supported.
As it stands right now I believe that the CUDA code will run whatever you
can create in Leap correctly. We have no test cases anywhere in the git tree
as far as I can tell for situations where the A and B coefficients for
specific ATOMType-ATOMType interactions are different. Indeed the parmXX.dat
and frcmod files never allowed for this:
- 10 - ***** INPUT FOR THE 6-12 POTENTIAL PARAMETERS *****
LABEL , KINDNB
FORMAT(A4,6X,A2)
LABEL The name of the non-bonded input parameter to be
used. It has to be matched with "NAMNB" read through
unit 5. The program searches the file to load the
the required non-bonded parameters. If that name is
not found the run will be terminated.
KINDNB Flag for the type of 6-12 parameters.
'SK' Slater-Kirkwood parameters are input.
see "caution" below.
'RE' van der Waals radius and the potential well depth
parameters are read.
'AC' The 6-12 potential coefficients are read.
NOTE: All the non equivalenced atoms' parameters have to
be given.
The input is terminated when label .eq. 'END'
------------------------------------------------------------------------
- 10B - ***** ONLY IF KINDNB .EQ. 'RE' *****
LTYNB , R , EDEP
LTYNB Atom symbol.
R The van der Waals radius of the atoms having the symbol
"LTYNB" (Angstoms)
EDEP The 6-12 potential well depth. (kcal/mol)
------------------------------------------------------------------------
- 10C - ***** ONLY IF KINDNB .EQ. 'AC' *****
LTYNB , A , C
LTYNB Atom symbol.
A The coefficient of the 12th power term (A/r**12).
C The coefficient of the 6th power term (-C/r**6).
We have "NEVER" had any pair wise terms in the force field for VDW
interactions and thus it is perfectly reasonable to assume this is the case
inside the codes. The prmtop format technically allows it (by expanding in
terms of Pair-Pair interactions) but the force field files themselves have
never allowed it. Thus this really is a NEW feature being exposed by nature
of making it easy for someone to hack the prmtop file.
Hence I believe that with that comes the responsibility to test the various
modifications, document what does and doesn't work and then put checks into
the codes to trap conditions that are not fully supported. Perhaps someone
has an enterprising summer student who could do this for us? (Adrian??? ;-)
).
Beyond, I think for now the simplest approach is to make a note of this
somewhere so we don't forget it and label parts of parmed as 'expert only
and experimental' - that way at least people are warned.
Note ultimately if we want to support the NBFix hack from the Charmm force
field with Chamber prmtops we'll also need to address the off diagonal VDW
elements but as above that will probably have to wait for AMBER 13.
Sorry I can't bring better news but these sorts of situations are only going
to get worse, it is possible to have flexibility and still get performance
on modern machines. :-(
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
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-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun May 27 2012 - 17:30:02 PDT
