Re: [AMBER-Developers] some thoughts about sander and Amber12

From: Ross Walker <>
Date: Wed, 30 Nov 2011 09:42:07 -0800

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

> -----Original Message-----
> From: David A Case []
> Sent: Wednesday, November 30, 2011 5:35 AM
> To:
> 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 mailing list
Received on Wed Nov 30 2011 - 10:00:02 PST
Custom Search