On Wed, Feb 12, 2014, Jason Swails wrote:
> >
> > What's left in Sander that people crave for in PMEMD?
> >
>
> QM/MM.
Certainly, QM/MM is in sander but not pmemd. But do people "crave for it"
to be added to pmemd? The usual argument is that the QM part quickly becomes
the time bottleneck, so the fact that MM is faster in pmemd becomes
irrelevant -- there is little need (yet) to think about porting QM/MM to
pmemd. (I could be wrong here.)
Similar arguments apply for PBSA and RISM: these are both in sander, but
are slow, and limit performance. Again, any speed advantage PMEMD has for
the other parts of the calculation are minimal. So there is no hurry to
put PBSA or RISM into pmemd.
The emap functionality is similar, but maybe not identical, since it is not
as big a time-hog as QM, PBSA or RISM. So far, I don't think most emap
calculations (and there aren't very many of them, since only a few people
are using this capability) need highly efficient MM. But there is more of
an argument here that emap capability in pmemd might be desirable.
On the other hand, I don't really see Scott's argument, that emap (et al)
somehow make it hard to keep going on pmemd.cuda development. It's quite
modular, and there is a simple if-statement in mdin to disable this for GPUs.
We've always had a list of things that aren't supported for GPUs; having a
few more entires in that list doesn't seem that bad (to me). We're learning
how to document this better, both in the code and in the Manual.
Scott says he wants "more control ... on feature additions that will run
on the GPU." We *should* establish a better mechanism for suggesting and
vetting requests for new GPU features. But I don't (yet) see that another
code fork is needed to accomplish this.
...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 12 2014 - 19:00:02 PST
