I agree with Thomas's assessment of the impact free-izing sander will have
on paid-for Amber (and Kennie had good comments about why this is worth
avoiding) and I agree with Ross's suggestion to have 2 products: Amber
(Paid) with everything, and Amber (Free) with our open-source stuff.
We can always work out the details later, but Ross's approach has the
advantage that there's no implicit dependence on a static API (anywhere),
it doesn't restrict release schedule, and it is easy to maintain and
distribute.
We can always work out pricing schemes (e.g. have 1-year releases, and
consecutive licenses cost $200 to not increase costs for those used to
updating for $400 every 2 years, and $400 for non-consecutive licenses) and
directory structure (keep AmberTools directory or morph everything back
into src, test, etc.)/implementation independently of this decision.
My thought is that doing anything that resembles AT15 + Amber 11 is just
asking for trouble (and will turn up more unforeseen problems that we
didn't catch this time around).
I've (surprisingly) rather switched positions and think we should keep the
licensing status-quo.
All the best,
Jason
On Wed, Nov 30, 2011 at 12:42 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> What about my preferred option. Option 3?
>
> Put everything back into AMBER - call it AMBER12 and you can download the
> free parts from the website or you buy AMBER and you get everything?
>
> Simple, user friendly, easy to understand.
>
> And what is the big problem with RISM anyway? Is it just FFTW? - We've had
> the ability to link to FFTW in PMEMD for years and no one was ever bothered
> by that so I don't see the issue.
>
> All the best
> Ross
>
> > -----Original Message-----
> > From: David A Case [mailto:case.biomaps.rutgers.edu]
> > Sent: Wednesday, November 30, 2011 5:35 AM
> > To: amber-developers.ambermd.org
> > Subject: [AMBER-Developers] some thoughts about sander and Amber12
> >
> >
> > I'm trying here to summarize the options for how sander fits into the
> > next
> > release of Amber.
> >
> > Option 1 is to put sander into AmberTools. This might increase our
> > user
> > and contributor base (about a dozen people a day download AmberTools).
> > It
> > also cleanly solves the problem of keeping Amber and AmberTools
> > separate,
> > allowing independent updates to both. But it means that "Amber"
> > essentially becomes pmemd, the fast, parallelized, gpu-ized simulation
> > engine. It then competes more or less head on with NAMD, Desmond,
> > Gromacs, and (maybe) openMM, all of which people use to run the Amber
> > force field fast. There is potential dilution of the Amber "brand",
> > and
> > loss of income if people who currently pay for (pmemd + sander) choose
> > not
> > to pay for pmemd alone.
> >
> > Option 2 is to keep sander in Amber, but to (somehow) guarantee that
> > updates to Amber and AmberTools remain independent (avoiding the
> > problems
> > we had with AT1.5). There are three main places where sander and
> > AmberTools overlap:
> >
> > a. RISM. If sander is in Amber, then we can't release sander.RISM
> > because of licensing restrictions. So there is no overlap, but
> > users don't get to run RISM inside sander.
> >
> > b. PBSA. This is harder, but the interface (API) between sander and
> > pbsa code is pretty simple and stable. So we might be able
> > to commit to not changing the way sander calls pbsa routines,
> > allowing improvements in AmberTools to propagate to sander. We'd
> > have to solve the test-case problem, though: a new version of
> > AmberTools would have to be able to update the Amber test suite,
> > if that was needed.
> >
> > An alternative is to duplicate code, "freezing" the pbsa in sander
> > at its release, and having the AmberTools pbsa code in a separate
> > directory. Prior to the release of Amber 13, we'd have to copy
> > any
> > improvements in pbsa from AmberTools to Amber--probably not too
> > hard
> > if the API stays almost the same.
> >
> > c. SQM: much the same as pbsa, except that the interface between QM
> > and MM is much more likely to change in a major fashion, so the
> > problems are harder. One possibility is that sqm in AmberTools
> > is just a stripped-down version, used only/mainly for am1-bcc
> > calculations, and all the "real" development goes on in the Amber
> > source code tree. This involves some code duplication, but the
> > stripped-down version in AmberTools probably won't change very
> > often. Disadvantage is that we no longer off a free DFTB/MNDO
> > code,
> > which might have filled a nice niche.
> >
> > I'd like to get *brief* comments (not flames) on the above. This is
> > not
> > the time to worry about details (e.g. what the directory trees might
> > look
> > like), but to try to decide at a high level whether we want option 1 or
> > 2,
> > and (for option 2) how best to handle items b and c above. In
> > particular, I
> > am interested in getting opinions from the people actually working on
> > the pbsa
> > and sqm codes.
> >
> > [One other point to think about: for either option, how often would
> > we expect to have new releases? For example, is it likely that GPU
> > code and hardware changes will continue as in the recent past, such
> > that we will need to have updates to pmemd sooner than two years? Same
> > question for sander, especially for the QM/MM part, which is seeing
> > lots
> > of development. My current feeling is that our old model of having a
> > release every two years is not going to continue to work--we have a
> > larger
> > developer base and increased "competition".]
> >
> > Apologies for being long-winded.....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
>
--
Jason M. Swails
Quantum Theory Project,
University of Florida
Ph.D. Candidate
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Nov 30 2011 - 15:30:03 PST
