IMO PMEMD is reaching the point of collapse.
There are way too many if/then clauses splattered all over the code with a
disturbingly high number of them in inner loops.
I am not going to be able to add many more features to the GPU codebase and
I am beginning to consider splitting off from the main tree so that more
control can be enforced on feature additions that will run on the GPU.
Softcore TI is going to be a bear to get running efficiently. And it's
hard for me to shake the feeling that the methodology is not quite ready
for primetime. Add in EMIL, EMAP, and the remaining potpourri of potential
features I hadn't heard of until the past few weeks and I'm reaching my
limit here. Maybe it's time to deprecate and remove some stuff before this
becomes Sander Mk II?
Just my two cents...
Scott
On Wed, Feb 12, 2014 at 1:32 PM, David A Case <case.biomaps.rutgers.edu>wrote:
> On Wed, Feb 12, 2014, Ross Walker wrote:
>
> > One thing I would like to avoid though as much as possible is people
> > adding incomplete new methods to PMEMD. E.g. adding a new VDW potential
> > but not supporting IPS or GB. We shouldn't be doing this unless there is
> a
> > real technical reason for not being able to do it.
>
> I agree, but would argue that we should *not* allow 12-6-4 and GB
> together, since it (12-6-4) was never parameterized for that model, and I
> have a general bias against allowing (or at least, against encouraging)
> explicit ions in GB simulations. I hope it's easy to catch that
> combination and disallow it (in both sander and pmemd.)
>
> This could, of course, be revisted in future releases, if the combination
> is
> demonstrated to be useful.
>
> On a related note, should we not remove (or #ifdef out) the "charge
> relocation"
> model? I don't think that has been well tested enough to support
> publically. The clean thing to do would to make a new branch, then remove
> traces of this in the master.
>
> ...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 - 14:30:02 PST
