I believe the 'thing' people pay for should still be called AMBER - Lots of companies have approval for purchasing AMBER - if we suddenly change the name of what they are buying it will generate paperwork etc.
So I think we should just simply have a free component of AMBER and a premium component. Simple solution would be to get rid of this weird AmberTools Fork - which I never liked in the first place since it just complicated build procedures, meant for a while we had multiple manuals and had to explain things in the tutorials etc and instead just finally merge everything back under AMBER - call it AMBER 15, roll in all the updates so far to pmemd and make the current git tree version of pmemd the AMBER 15 pmemd - move all the AmberTools out of it's own folder and back into the main source folder and then just have it be a standalone thing - consisting of two tar balls - Amber15.tar.bz2 and Amber15Pro.tar.bz2 or something like that (maybe have that include the Amber15 tar ball so we don't have this confusing thing of having to download two different things)
This way we don't have any confusion with whether someone has AmberTools 15 with Amber 14 etc etc.
Nice and simple and we can offer everyone who purchased AMBER 14 a one time free upgrade - they can use their existing login key for the website etc etc.
All the best
Ross
> On Feb 19, 2015, at 12:56 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
>
> I also vote for Amber15. In my opinion this causes the least amount of
> confusion and we stay consistent with the current numbering strategy (by
> year).
>
> Just a few more random thoughts here, so don't shoot me for thinking out
> loud. I wonder if (not for this release of course!) we want to start
> revisiting the current Amber/AmberTools split. Right now the only non-free
> part of Amber is pmemd, so it's really kind of its own entity. We could
> think about just getting rid of the AmberTools subdivision completely and
> have everything that is currently AmberTools be in 'amber16', 'amber16/src'
> etc (like it used to be), and have the pmemd source in a completely
> separate directory (like pmemd16). This way Amber is just basically
> AmberTools, and pmemd is the optional DLC you pay for. Since pmemd doesn't
> require that AMBERHOME is set (that I know of) this shouldn't break
> anything in terms of how pmemd functions. The 'mkrelease' script framework
> should give us the ability to create functioning separate tarballs. The
> advantage here is users would always know what version of things they have.
> Also, stuff that is released yearly is kept together, while stuff that is
> released biennially is kept separate. There would have to be a few changes
> to the configure framework (the script would need some way of knowing
> whether its working for Amber or pmemd; the update script too), but it
> seems like it might not be too bad; I was able to compile pmemd in a
> completely separate environment and all that was needed was giving it a
> copy of AmberNetcdf.F90 and using my system netcdf. There's already some
> separation in the config process in that a bunch of pmemd-specific flags
> are written to config.h.
>
> Maybe in the end it's a lot of work for not too much benefit, but it's
> something I've been thinking about.
>
> -Dan
>
> On Wed, Feb 18, 2015 at 12:08 PM, Jason Swails <jason.swails.gmail.com>
> wrote:
>
>> On Wed, 2015-02-18 at 11:58 -0500, David A Case wrote:
>>> Hi everyone:
>>>
>>> Here are a few points that came up at the recent developers' meeting:
>>> (see photos at the Amber web site)
>>>
>>> 1. Please visit and update the contributors' page:
>>> http://ambermd.org/contributors.html
>>>
>>> 2. Please update publications in the Reference Manual; add new relevant
>>> publications. If you don't cite your papers, who will?
>>>
>>> 3. We need a good way to refer to the combination "AmberTools15 +
>> Amber14".
>>> At the meeting, I indicated a preference for just calling this
>>> "Amber15", but I think that is likely to be quite confusing.
>> Maybe
>>> there is no shorter name that works, but suggestions are welcome.
>>
>> Amber 14.5? 2 years from now it can be Amber 16.7? Amber
>> 84317ac3609010bb08ccfeb2893c72a3 (sum of the md5sums of
>> AmberTools15.tar.bz2 and Amber14.tar.bz2)? [1] :)
>>
>> Personally I prefer Amber 15. AmberTools has all of the functionality
>> of Amber, just not its performance. And it isn't like we're treating
>> Amber 14 as a "bugfix-only" release right now -- it has a lot more
>> functionality now than it did last April. But I see the case for this
>> causing confusion.
>>
>> All the best,
>> Jason
>>
>> [1] Just a demo. This is the sum of AmberTools14.tar.bz2 and
>> Amber14.tar.bz2 for now.
>>
>> --
>> Jason M. Swails
>> BioMaPS,
>> Rutgers University
>> Postdoctoral Researcher
>>
>>
>> _______________________________________________
>> AMBER-Developers mailing list
>> AMBER-Developers.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>
>
>
>
> --
> -------------------------
> Daniel R. Roe, PhD
> Department of Medicinal Chemistry
> University of Utah
> 30 South 2000 East, Room 307
> Salt Lake City, UT 84112-5820
> http://home.chpc.utah.edu/~cheatham/
> (801) 587-9652
> (801) 585-6208 (Fax)
> _______________________________________________
> 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 Fri Feb 20 2015 - 14:30:03 PST
