To add a little more to this. The problem is not the addition of extra
features in the code etc. It is the addition of extra features a few weeks
to a couple of days before the code freeze without having consulted with
any of the key people working on the code before that date. Realistically
we need far better coordination here. Those responsible for a given code
and it's performance - for example in PMEMD right now that would be me,
Scott Le Grand, Perri Needham, Joe Kaus, Adrian Roitberg and Jason Swails
- We all talk on an almost daily basis on skype and coordinate everything.
Where was the coordination from the others - who just dump stuff in? Why
was the addition of the code not discussed with us several months
beforehand?
Those not directly responsible for a given code should have been frozen
from submitting some 6 months ago - and even better the freeze should have
been random without people knowing how their freeze related to others -
that would prevent a ton of changes right down to the wire.
Scott, Perri, Joe and I have a clear plan for PMEMD, PMEMD.MIC and
PMEMD.CUDA for the upcoming release. Those wanting to add features to
pmemd would have been advised to work with us - in the end it would make
less work for everybody involved.
I am not trying to keep people out of the code here - I just advocate that
the traditional scientific practice of working in a vacuum is what led to
the mess that is sander, we do not want to repeat that with PMEMD and thus
we should not allow it.
Perhaps we should have weekly group meetings for PMEMD code development in
future - if you don't attend them and contribute on a regular basis you
don't get to add stuff?
All the best
Ross
On 2/17/14, 9:19 PM, "Duke, Robert E Jr" <rduke.email.unc.edu> wrote:
> Well, flawed in the sense of "hard to fund...". I had to drop pmemd
>because I couldn't work on it full time without funding, and really
>needed to work on it a fair bit to keep it moving. I would argue that
>you can get better software from a smaller team, and the model of having
>somebody actualize the final code is not all that flawed, aside from the
>funding problem (I know, a big "aside"). Separating the science from
>performance-critical software dev is not a bad idea in many many ways.
>Just my opinion, but I view the software, taken to the limits, as a
>specialty you guys typically don't have time for...
>Regards - Bob (and Hi! Scott B.)
>(and I completely understand Scott L.'s issues with just anything getting
>shoved into performance-critical regions - it is a much harder thing to
>keep the bloody thing fast than I think is widely appreciated..)
>________________________________________
>From: Scott Brozell [sbrozell.rci.rutgers.edu]
>Sent: Monday, February 17, 2014 8:42 PM
>To: AMBER Developers Mailing List
>Subject: Re: [AMBER-Developers] New features in pmemd
>
>Hi,
>
>On Wed, Feb 12, 2014 at 09:46:15PM -0500, David A Case wrote:
>> On Wed, Feb 12, 2014, Jason Swails wrote:
>> > >
>> > > What's left in Sander that people crave for in 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
>>...
>> 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.
>
>1.
>Why not create a 'new features' Severity bug in bugzilla
>and cc the am-dev list when it is created:
>Every developer should be subscribed to am-dev, so every developer
>gets notified. Those that want to vet can do so via bugzilla.
>
>2.
>I agree that existing-feature-bla may not merit another code fork.
>But let me throw out another code fork:
>heterogeneous-platform-ambermd
>Its design would be along the lines of the gromacs 4.6 rewrite
>where, eg, non-bonded forces, are offloaded to gpus or other compute
>resources.
>
>As usual any individual can pick and choose from the pro's and con's
>to make their case. Here's two important pro's:
>A. The gpu-only and cpu-gpu architectures both have merit.
> It is not forward looking to cede cpu-gpu to gromacs or namd or...
> LAMMPS has both.
>B. The Scott Legrand will do our programming for us model is flawed
> in the long run just as was the Bob Duke ...
>
>scott
>
>
>_______________________________________________
>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 Mon Feb 17 2014 - 23:00:03 PST
