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
Received on Mon Feb 17 2014 - 21:30:04 PST
