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
Received on Wed Nov 30 2011 - 06:00:06 PST
