On May 28, 2012, at 10:22 AM, "Ross Walker" <ross.rosswalker.co.uk> wrote:
>> 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 :-( ).
I'll get to it, but since it doesn't affect many people, it will take me awhile to make sure I make a working bugfix ;). For now a note should suffice (I'll put it with my parmed tutorial on my wiki, since I think most people that will use parmed for advanced stuff will probably reference that site).
It would also help if people documented assumptions they make when explicitly ignoring data in the prmtop. Not that ignoring data should never be done, just that it should be documented, I think.
Another example is that PME ignores the exclusion list, but GB doesn't. (at least for sander).
There is way too much flexibility and complexity in parmed and molecular simulations we can run in Amber for me (or anyone) to be able to validate EVERYTHING someone can do with parmed for every code. A warning to be careful when doing prmtop mods I think is the best we can do (and I think I already have a warning to that effect in the manual).
> 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?
In everything before pmemd.cuda, yes (we just didn't release something that could modify off-diagonal terms until now), but every code supported it if the prmtop had it.
> As it stands right now I believe that the CUDA code will run whatever you
> can create in Leap correctly.
Not quite. I mentioned that pmemd.cuda does not support the OPLS, since it uses different combining rules than amber. tleap supports the OPLS FF with its combining rules, or so I've been told. (and it wasn't my responsibility to put that check into pmemd.cuda ;), though I would have if I had known about it in time).
All the best,
Jason
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun May 27 2012 - 23:00:02 PDT
