I'd call for Option 3 myself to try and optimize the pros and cons of
Option 1. This idea was proposed by Ross, though I'm adding some
details. Overall, I think it offers a good compromise between the two
options.
While I initially suggested option 1, I think some of the cons have
swayed my position slightly. Here is my (Ross's) option 3:
AmberTools is required for Amber, and there are enough dependencies on
AmberTools that Amber cannot be considered truly "separate" (for
example, sqm, pbsa, etc., and netcdf is another example). Another
downside of separating the two directories comes when it's time to
"update" AmberTools if the releases really are off-sync (as they
should be I think). When AmberTools is updated, Amber itself will
have to be recompiled, and we are left with the restriction that each
version of AmberTools be compatible with each version of Amber after
10 or 11 (or, of course, the user must have two, separate directories
for a version of AT compatible with their version of Amber and the
latest version of AT, and this runs the risk of being far more
complicated than even the current situation). I still think an AT
should be released with Amber, but I think not releasing AT until we
release Amber poses an unnecessary restriction. Therefore, to
optimize the pros of both options, i propose selling Amber as a *full*
package (including the current AmberTools at the time Amber is
released). This way, we can combine the configure script and
Makefiles to build everything at once, which will simplify the process
of compiling (this is only a side-benefit, as typing make -f
Makefile_at and make serial separately shouldn't stress the abilities
of users). Then, each time we release AmberTools as a separate
download, it unpacks into an AmberTools directory that simply has a
different Makefile designed only for AmberTools (i.e. doesn't try and
build portions of sander). While this causes code to be duplicated in
both directories, I don't think that's an issue. A hard drive that
can't support two copies of AmberTools is a hard drive that can't
support a trajectory worth analyzing anyway, and it allows us more
free reign in updating sqm, pbsa, etc. without making sure that it'll
always be back-compatible (and then, of course, it would break all of
the tests).
This combines the best of the separation and combination ideas, such
that AmberTools is truly seen to be part of Amber (since amber isn't
released without it), and AT also appears stand-alone. We also need
not change $AMBERHOME at all (it must point to the latest
AmberTools... etc, but this is easy to explain). I think this context
is also an argument for consolidation of Makefiles, since explicitly
compiling "ambertools" in the amber directory and then again in the
AmberTools directory (after AT is released between Amber releases) may
seem confusing (it certainly does now), while we can have Amber
installation instructions and AmberTools installation instructions,
and insist that AMBERHOME points to the latest AmberTools.
I do think this is the most elegant solution as it maintains ease of
use for the user while allowing developers maximum flexibility in
developing and releasing AmberTools. I think this change would be the
easiest one to implement as well, since no changes would need to be
made before the Amber11 release, etc.
Thoughts?
--Jason
On Sat, Jan 30, 2010 at 9:22 AM, case <case.biomaps.rutgers.edu> wrote:
> At the developers' meeting, there were various suggestions for how to
> handle the Amber/AmberTools split. This is a request for comments for some
> ideas along this line.
>
> Option 1:
> unpack Amber into a tree headed at Amber-11.0/
> unpack AmberTools into a tree headed at AmberTools-2.0/
>
> Each would be a full and separate package. Users would set AMBERHOME
> to the AmberTools-2.0 location, since Amber codes don't use such a
> variable. Users would put both Amber-11.0/bin and AmberTools-2.0/bin
> in their PATH.
>
> Amber users would still need AmberTools, as in a package dependency.
>
> Pros:
> Simple to explain to users. We could upgrade AmberTools without
> worrying about Amber. Amber tests and AmberTools tests would be
> cleanly separated.
>
> Having versioned directory names is more in line with gnu/linux software
> practices.
>
> We could support different compilers/OS's in AmberTools than in Amber;
> the configure script and config.h file would not be required to be the
> same. For example, we would probably not need to support pgcc for
> AmberTools.
>
> Cons:
> Considerable code duplication: sqm, pbsa, rism, lib (others?) would
> be present in both releases. Bug fixes would have to be made in two
> places, using different patch files as the two codes diverge. If we
> indeed have AmberTools releases not coordinated with Amber releases,
> then we have the awkward situation that the functionality and results
> for the same calculation (e.g. QM) are different in the two codes.
> If we truly separate the two parts, we would need massive documentation
> duplication as well as code duplication.
>
> Hard for developers, since the tree that users would see is different
> from the one we are developing on. (This is probably a minor concern.)
>
> Psychologically, we weaken the perception that AmberTools is a "genuine
> part of Amber". (This might be a rather important drawback; or maybe
> not.)
>
> Option 2:
> Continue with the current model: both codes unpack into an amber11
> tree, which AMBERHOME points to. We make sure that any updates to
> AmberTools (either through bugfixes or an intermediate release) remain
> compatible with Amber -- no more "jumping ahead" to a new directory
> tree as we did with AmberTools-1.3.
>
> Pros:
> Doesn't have the "cons" of Option 1.
>
> Cons:
> Doesn't have the "pros" of option 1. Might be quite difficult to meet
> the requirement that changes in AmberTools have to "work" inside the same
> tree as Amber itself. Hard to keep licensing terms clear when code with
> very different licenses reside inside the same tree.
>
> Option 3:
> Something different from the two listed above.
>
> Comments? I'd like to get this figured out soon, since attempts to clean
> up the installation (e.g. merge src/Makefile with src/Makefile_at) depend
> on what we decide.
>
> Please think hard about the branding and perception issues -- the other things
> are mostly technical that we can probably solve.
>
> ....thx....dac
>
> _______________________________________________
> 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. Graduate Student
352-392-4032
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 30 2010 - 09:00:03 PST
