On Sat, Jan 30, 2010 at 5:23 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> I like the way Jason has put this. To reiterate my point from the AMBER
> meeting an my experience from trying to explain this multiple times at
> workshops I believe it should be like this:
>
> 1) If you purchase AMBER 11 you should get a COMPLETE package. That is
> AMBERTools, Sander and PMEMD all in one package that extracts into a single
> directory, has a single configure script, single makefile and single set of
> test cases.
>
> Trying to explain to people that they have to download AMBERTools
> independently just confuses them. They ask. "So what did I buy?"
>
> Look at what has happened with the AMBERTools 1.3 release. Now we have AMBER
> 10, and have to get a separate AMBER Tools 1.2 from it, then we have
> AMBERTools 1.3 extracted into AMBER 11. But no sander or pmemd in there yet.
> Then where will AMBERTools 1.4 go? Amber 12??? From an end user perspective
> it is just hopelessly confusing and trying to explain it to newcomers is
> even harder. They just look at you like you are crazy.
>
> So what I want to know is why we can't have the following:
>
> AMBERTools -> Various versions of this extract into AMBERTools1.x
> directories. These are COMPLETELY independent of AMBER.
>
> AMBER11 and subsequent versions come containing everything including a
> compatible version of AMBERTools and the division of AMBERTools is not
> present. I.e. AMBER looks like a complete package. Single AMBERHOME pointing
> to well, the home of AMBER - where the AMBER package is installed. Not where
I agree with everything except here -- AMBERHOME is only used by
ambertools programs. Perhaps AMBERHOME should be recast as
AMBERTOOLSHOME and AMBERHOME can stay as the home of AMBER simply to
aid in the understanding of the tutorials (but not actually USED by
any of the programs. This seems to be a change we can save for
versions past Amber11, and we wouldn't have to address this until
after Amber11 is released, a win-win). However, users of Amber (even
the latest version), should be able to (and even encouraged to!)
update to the latest version of AmberTools (which I hope is released
more often than Amber). Thus, we can keep a single tree and, like Ross
said, have a mkrelease_at that will dump everything into an
AmberToolsx.y directory that includes only the Makefile_at that only
builds AT.
The mkrelease for Amber, on the other hand, packages EVERYTHING
(*except* Makefile_at, as the ambertools make should be controlled by
the regular Makefile that makes everything -- deciding whether to
include pmemd in this is another issue, and quite independent of the
current discussion).
The instructions remain clear for the users -- AMBERHOME points to
Amber, and AMBERTOOLSHOME points to the latest installation of AT
(which may, shortly after an Amber release, be identical to
AMBERHOME). I think this is the simplest solution short of combining
everything under the same license. One thing we'd have to keep in
mind is to tell users to add $AMBERTOOLSHOME/bin/ to PATH before
$AMBERHOME/bin so that the latest version of AT executables are used
first.
The simplicity of the above is that AMBERHOME should still be set to
amber11/ for the upcoming release, and we can introduce AMBERTOOLSHOME
then (even though it won't do anything, AMBERHOME will, and we will be
set to switch over to AMBERTOOLSHOME where necessary for the next AT
release).
The above maintains the marriage of AmberTools and Amber for Amber
purchasers while simultaneously showing AT as a potentially standalone
package (as should be implied by the separate licensing) for those
wishing to upgrade more frequently than they upgrade AMBER, or simply
use it as a tool suite for another program.
I'm sorry if I appear to be beating a dead horse, but I think I more
fully explained my suggestion here (as rereading my previous post
again it seemed rather confusing at points). This is the conclusion
of my $.02.
All the best!
Jason
--
---------------------------------------
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 - 15:00:02 PST
