> After an update of AmberTools, we then have two versions of everything
> except sander and pmemd (or, everything except pmemd). Maybe there is
> some
> clever versioning scheme that can keep it straight, but at what price?
> I suspect (and hope!) that most users will upgrade when an improved
> version of
> AmberTools is released, so very little is gained by having Amber12 be a
> "complete package" (i.e., it becomes a "complete but outdated
> package").
> But we would still be kind of obligated to support the "official
> Amber12"
> package for two full years.
But I don't see the difference between what I suggest and what you are
describing here. What I am suggesting is the following:
1) We unify everything into a single src tree with a single configure
script, single master makefile and single set of test cases.
2) We create a makerelease script that will either build a tar file of
'AMBER' or a tar file of 'AMBERTools' - the key being that AMBER includes
AMBERTools explicitly.
3) The configure, makefile and test scripts should then be smart enough to
detect if the result of the untar produced a copy of AMBER or a copy of
AMBERTools - again with AMBERTools being a subset of AMBER.
This makes it significantly easier for the user and, in my opinion, prevents
the watering down of the AMBER brand that we currently have.
Then when it comes time to upgrade and release an updated AMBERTools all we
do is use the makerelease script from the current git tree to build the
AMBERTools tar file.
The question then becomes what someone does with the contents of this new
AMBERTools tar file. Option 1, which I believe is logically equivalent to
what we have now is that you untar it into the AMBER 12 directory thus
upgrading the AMEBRTools parts of the code - clearly we'd need an upgrade
script to do this properly but this is no different from the current
situation where one has to erase the AMBERTools directory and recompile
everything anyway.
Option 2 is it gets untarred into an AMBER12.5 or AMBERTools12.5 directory.
This of course adds confusion to what version is to be run on a machine.
Although I have for a long time believed that the version number should be
in the environment variable. I.e. we should have AMBER11HOME, AMBER12HOME
etc - would certainly solve a lot of issues on the supercomputers where one
actually wants 3 or 4 versions of the code installed, AMBER9, 10, 11 etc.
> In addition, I think users are by now quite used to the current setup,
> where AmberTools is open source and Amber isn't. (This also avoids
> confusion
> about what license goes with what code.)
I dispute this. At every AMBER workshop it just leads to confusion. Many
many people have asked me why we don't just have a single unified build and
test system. Certainly it does make the licensing of the various parts of
the code obvious but it certainly doesn't make it clear to people why AMBER
itself is not a complete package and needs you to download, compile and test
and additional set of code.
> [Note that I think we are committed to the notion that future upgrades
> to
> AmberTools must be compatible with the latest release of Amber itself.
> Exactly how we do this depends on what we decide to do about sander,
> which
> is still under discussion.]
If this is indeed the case then having everything centralized as an AMBER12
or an AMBERTools only version of AMBER12 should not be an issue and does not
suffer from the upgrade issues that Jason initially put forward but it does
avoid all the confusion about why AMBER itself should not be all inclusive.
A paid for and a free version of AMBER seems to make perfect sense to me.
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 03 2011 - 21:00:02 PDT
