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
Received on Wed Feb 12 2014 - 15:00:02 PST
