Re: [AMBER-Developers] separation of Amber and AmberTools?

From: Volodymyr Babin <>
Date: Sat, 30 Jan 2010 11:31:40 -0500 (EST)

Hi everyone:

IMHO there is no time left for separation for this release.
Otherwise, apart from branding issues, this is certainly a
good idea.

With kind regards,


On Sat, January 30, 2010 09:22, case 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 mailing list
Received on Sat Jan 30 2010 - 09:00:02 PST
Custom Search