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
Received on Thu Feb 19 2015 - 13:00:02 PST
