It's relatively easy (though awkward) to fix OPLS support, but adding
support for manual tweaking of off-diagonal entries will cost SM 1.3
support for the entire program for a variety of reasons, and even then,
there will be a performance cliff when shared memory is exhausted. My own
opinion is that off-diagonal hacking is really ill-specified at this time
and it would be better to clean that up into something more obiously
specified in a machine-readable format before it goes any further.
Pmemd.cuda derived its behavior from the force field definition not the
actual values in the cn1 and cn2 tables which seemed to be
machine-generated (and IMO) ought to remain so.
Scott
On Sun, May 27, 2012 at 4:40 PM, Jason Swails <jason.swails.gmail.com>wrote:
>
>
> On May 27, 2012, at 11:28 PM, case <case.biomaps.rutgers.edu> 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?
>
> No error messages/warnings. It implicitly assumes nobody (or parmed) has
> messed with off-diagonal (or only-diagonal) elements of the coefficient
> matrices). The only way to warn really would be to check that all of the
> computed coefficients match with the ones in the prmtop. I can work on this
> check when I get a chance (but being in a state of flux right now I don't
> know when that will be).
>
> I discussed this to a decent extent with Scott, who will likely chime in
> here. The issue is that the performance hit will be pretty severe if we
> can't fit the A and B coefficient matrices in shared memory. Since the
> shared memory is pretty much tapped out at this point, it's likely that it
> won't fit and performance will severely suffer. That's why the decision was
> made to actually apply the combining rules each time rather than use
> pre-computed ones.
>
> This also means, incidentally, that the OPLS force field is not properly
> supported by pmemd.cuda since the original NB coefficients are de-combined
> and re-combined using the Amber combining rules. This was a relatively
> recent discovery of ours which I haven't gotten a chance to really pursue.
>
> I hope this clarifies things a bit.
>
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon May 28 2012 - 09:00:02 PDT
