As an additional note, you could allow for "overinstall" of a new ambertools
in the last amber release if it was compatible. On incorporating pmemd
configure/make into the broader scheme, you may want to be a bit careful on
that. It was originally separate so I would have full control of
optimization, and that is still an issue - there is all kinds of
target-specific conditional compilation and a bunch of target machines not
otherwise supported by the rest of amber. I have not been keeping up on
this partly because my machine base has shrunk, and I am sure that with
platform consolidation it is less of an issue overall, but you really do not
want, in the name of convenience, to do things that limit performance at the
supercomputer centers.
Regards - Bob
----- Original Message -----
From: "Robert Duke" <rduke.email.unc.edu>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Saturday, January 30, 2010 7:44 PM
Subject: Re: [AMBER-Developers] separation of Amber and AmberTools?
> Okay, so simple solution. Have an amberx directory (11, 12, etc.). Under
> the amberx directory, have an AmberTools directory. Encapsulate all of
> ambertools this way, but within the main tree. Have the makes work
> recursively, recursing into Ambertools first. Seems that might be
> reasonably organized and clear, with everything logically in one package,
> but divided out so that there is not massive confusion about what's
> ambertools and what's the rest of amber... That way everything still
> works from an $AMBERHOME, it is possible to reference the correct
> ambertools release from the rest of amber by the $AMBERHOME-relative path,
> and anyone that installs ambertools by itself can have the same basic
> structure, but not fully populated. However, they do have to reset
> $AMBERHOME or paths to use say just a new release of ambertools vs. the
> latest full install of amber. But ambertools is clearly distinguishable,
> self-contained, built as a subset, and not replicated.
> Regards - Bob
> ----- Original Message -----
> From: "Ross Walker" <ross.rosswalker.co.uk>
> To: "'AMBER Developers Mailing List'" <amber-developers.ambermd.org>
> Sent: Saturday, January 30, 2010 5:23 PM
> Subject: RE: [AMBER-Developers] separation of Amber and AmberTools?
>
>
> 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
> AMBERTools is installed. That is just confusing.
>
> To avoid code division here I think we keep everything in a single CVS
> tree
> and we just have scripts, like mkrelease that will build either a full
> AMBER
> X or a cutdown AMBERTools. The take home point though is that I firmly
> believe that AMBERTools should be a 'subset' of AMBER and not some
> independent, but strangely intertwined separate entity.
>
> My 3C.
>
> All the best
> Ross
>
>> -----Original Message-----
>> From: amber-developers-bounces.ambermd.org [mailto:amber-developers-
>> bounces.ambermd.org] On Behalf Of Jason Swails
>> Sent: Saturday, January 30, 2010 8:51 AM
>> To: AMBER Developers Mailing List
>> Subject: Re: [AMBER-Developers] separation of Amber and AmberTools?
>>
>> 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
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 30 2010 - 17:00:03 PST
