You *could* release AMBER 12 PMEMD as the new Sander.
And then make AMBER 14 PMEMD invite-only featured.
What's left in Sander that people crave for in PMEMD?
On Wed, Feb 12, 2014 at 2:35 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> The problem is it's a victim of it's own success. People used to put stuff
> in sander and if it was used a LOT it was migrated to pmemd. Now they want
> to just put it straight in pmemd since to be honest if it's just in sander
> its kind of useless these days.
>
> The problem is how to deal with this and yes I fully agree ALL of this
> should have gone in over the last year. I vote once things are locked on
> Friday we have at least another 6 weeks to work on cleaning up pmemd and
> optimizing things ready for release. This may include gutting some stuff.
> Otherwise yes we will just end up with a slow pmemd. :-(
>
> All the best
> Ross
>
>
> On 2/12/14, 2:13 PM, "Scott Le Grand" <varelse2005.gmail.com> wrote:
>
> >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
>
>
>
> _______________________________________________
> 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 - 15:00:03 PST
