[gmx-developers] plans for GROMACS 5.0 beta December 1

Justin Lemkul jalemkul at vt.edu
Fri Sep 27 16:20:02 CEST 2013

On 9/27/13 8:55 AM, Mark Abraham wrote:
> Hi devs,
> The time has come to make concrete plans in the lead-up to 5.0. On this list on
> February 8 I said:
>     We're acutely aware that the timeline for previous GROMACS releases has been
>     vague and has drifted on endlessly. This will change. In future, we will
>     produce timed releases, rather than feature-driven releases. If a feature is
>     not complete enough for the release roadmap, it will wait for the next
>     release, or be included in only partial form. For 5.0:
>     * any large-scale code patches hitting lots of code paths will need to be
>     largely complete by November 1, 2013 to allow adequate time for testing how
>     well they work with features of GROMACS that were not upper-most in their
>     authors' minds as they wrote them
>     * betas will be released over December and January (after beta1, no new
>     features, no planned API changes, no features expected to be removed;
>     considerations of correctness and performance will drive decisions here)
>     * release candidate 1 on February 1, 2014
>     * final release of 5.0 around March 1, 2014
>     The dates are guidelines, and the core team will use its judgement about how
>     strictly to follow them, but they will be flexible on the scale of days, not
>     months.
>     Subsequent major releases will happen at least once a year.
> This is still the plan. Major stuff should be visible in gerrit for review (and
> work on integration) by early November. Things do not have to be "feature
> complete" at that time, but by December 1 the core functionality needs to seem
> to work. Bug fixing is certainly expected. Minor feature completion can occur in
> the early parts of the beta phase (e.g. I think "make this integrator work with
> the pull code", "apply OpenMP to this bottle-neck", "fix CMake hackery" are all
> OK, but not "add kernels for Haswell," "add support for <fancy new QM package>,"
> or "refactor t_your_least_favourite_struct"). I'm not keen on deferring a whole
> feature from beta1 with a plan to put it in beta2. I think that just leads to
> deadline creep, because now that feature has had less of any beta testing. The
> subset that works should go in beta 1, and we can evaluate at the time whether
> the remaining changes are minor enough to accept for beta 2.
> There is no guarantee anybody's pet feature will get in. Every change is
> competing for limited reviewer resources, so you will need to do your best to
> look good. That means
> * building your karma by participating in review,
> * having your work in progress on gerrit, so you can take advantage of Jenkins
> testing,
> * having your branch merged up to date,
> * constructing commits that implement a single logical entity
> * having Doxygen documentation of the code,
> * updating the manual at the same time,
> * having used admin/uncrustify.sh to prettify your code, and
> * showing working test cases.
> Help with all these things is available - do ask on this list/Redmine/gerrit!
> Things we discussed in Stockholm this week that I'm aware people plan to
> prioritise trying to get into 5.0 are:
> * get Verlet kernels feature complete, and consider using a kernel generator
> script (perhaps also for GPU) - Erik, Berk, Szilard
> * MD loop and data structure cleanup - Mark
> * implement new integrator formalism - Michael, Mark
> * LJ-PME - Christian, Erik
> * TNG - Magnus, Mark
> * new QM/MM handling - David + team
> * improved collective error handling - Szilard, Mark
> * enhancements to pull code? (I forget now what this was about!)
> * support for PDBx/mmCIF since PDB is deprecated - Rossen, Mark
> * porting some selected tools to new analysis framework - Rossen
> * analysis framework (and lots of other useful things) - Teemu
> Other stuff is welcome, but speak up fast!

One of the things I mentioned at the conference was to add new polarization 
methods.  It will hinge on all of the work being done on the integrators, so I'm 
in a bit of a holding pattern until I see how some of that shakes out.  In the 
redmine issue on mdrun features, Michael and David had expressed an interest 
here, as well, but I'm willing to do my best to spearhead it.  From talking with 
Michael at the conference, it should be relatively straightforward to do what 
we're looking at.



Justin A. Lemkul, Ph.D.
Postdoctoral Fellow

Department of Pharmaceutical Sciences
School of Pharmacy
Health Sciences Facility II, Room 601
University of Maryland, Baltimore
20 Penn St.
Baltimore, MD 21201

jalemkul at outerbanks.umaryland.edu | (410) 706-7441


More information about the gromacs.org_gmx-developers mailing list