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

[Tsjerk Wassenaar]

I think it is timely to also add the Rotational Constraints Algorithm from
Andrea Amadei, in a modified, robust, parallelized form, as I have it in
4.5/4.6. I could use a hand with the GIT/Gerrit stuff, though :)

Cheers,

Tsjerk


On Fri, Sep 27, 2013 at 4:20 PM, Justin Lemkul <jalemkul at vt.edu> wrote:

>
>
> 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
>
> --
> ==============================**====================
>
> 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 <jalemkul at outerbanks.umaryland.edu> | (410)
> 706-7441
>
> ==============================**====================
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://lists.gromacs.org/**mailman/listinfo/gmx-**developers<http://lists.gromacs.org/mailman/listinfo/gmx-developers>
> Please don't post (un)subscribe requests to the list. Use the www
> interface or send it to gmx-developers-request@**gromacs.org<gmx-developers-request at gromacs.org>
> .
>



-- 
Tsjerk A. Wassenaar, Ph.D.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130927/e0cd65d1/attachment.html>