> On Feb 12, 2014, at 9:46 PM, David A Case <case.biomaps.rutgers.edu> wrote:
>
> 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.)
I was interpreting this question in the context of making pmemd into sander and forking off a more stable version that is more like the Bob Duke days of pmemd cleanliness.
In that case, sander still has a lot to offer that it's not worth discarding for a "sandbox" pmemd. I was certainly not suggesting we port it to pmemd (although I thought about pretending to with a few commits of large blank files and some suggestive commit logs, just to see the fallout :)... But not really).
The rest I agree with.
Happy wintering east coasters
>
> 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 12 2014 - 19:30:03 PST
