[gmx-developers] plans for Gromacs 5.1 release
Berk Hess
hess at kth.se
Tue Dec 2 22:10:43 CET 2014
On 12/02/2014 10:02 PM, David van der Spoel wrote:
> On 2014-12-02 14:52, Mark Abraham wrote:
>>
>>
>> On Tue, Dec 2, 2014 at 2:20 PM, Carsten Kutzner <ckutzne at gwdg.de
>> <mailto:ckutzne at gwdg.de>> wrote:
>>
>> Hi,
>>
>> I am planning to contribute some functionality expansion for the
>> computational
>> electrophysiology module:
>> - more control about from where to where the swaps are done
>> - support for multi-atomic ions
>> - support for a variable number of groups for which atom counts are
>> kept stable (e.g. if one not only wants to control Na and Cl, but
>> Na, K, Cl)
>>
>> Each added feature would require additional input parameters and
>> thus
>> a change of the .tpr file format. Therefore it could make sense to
>> lump all functionality expansion together in one patch. From a
>> review
>> point of view it would however be nicer to do it in separate
>> patches.
>> What is the preferred approach?
>>
>>
>> From bitter experience, multiple patches in flight that bump the .tpr
>> version make for a lot of busywork and Jenkins traffic, since all of
>> them want to increment the same counter. There's some new machinery in
>> tpxio.c that make it harder for us to make erroneous
>> automatically-resolved merges, but if there's matching regressiontest
>> cases then those need re-generation and re-validation, and it's all
>> horrible.
>>
>> So, along the lines of the suggestion I made to Justin in this thread, I
>> would suggest planning for a commit tree that was
>> * add .tpr management gear (perhaps for all your new features, just for
>> convenience), together with a fatal error from mdrun.cpp that observes
>> that there's no implementation yet, so that the missing implementation
>> can't misbehave
>> * actually add features in some progression that makes logical sense to
>> a reviewer, e.g.
>> + general cleanup and preparation (because if there's no expected
>> change to functionality, it's easy to review), then
>> + any movement of existing code (easy to review, and helps people
>> rebasing features in the same source files), then
>> + add the new code and matching tests
>>
>> The advantage here is that Justin (and anybody else) also wanting to
>> bump the .tpr can get that sorted out and merged separately from
>> reviewing the content of the feature. If anybody's feature later doesn't
>> pass review, the above workflow is not ideal, but there's already some
>> defunct fields in the .tpr format, so I expect it would not be a big
>> deal to make sure the release candidate doesn't have a grompp that
>> suggests a feature should exist when it does not, and perhaps some later
>> Gromacs version would use them once the feature is ready to pass review.
>>
>> I'm open to alternatives, though!
>
> How about splitting off the inputrec in xml format from the topology?
> Not 5.1 for sure, and it would do away with the convenient single
> input file for mdrun concept.
We should have the inputrec in xml in the topology file. And modules
should process their own parameters, then for most users it doesn't
matter if some exotic algorithm adds some parameters.
>
> We also have to consider how to decide whether patches to mdrun should
> be in the main code or not, or whether these could remain optional,
> e.g. by implementing hooks in the code where "custom" routines can be
> called from, without mdrun having to "comprehend" what is going on.
Yes, that is the way to go. We current is, and has always been, an issue
that it's difficult to adds new, more socialistic functionality since it
soon or later needs to be maintained by the core developers. Having
external modules removes this burden and should make it much easier for
more people to add functionality and distribute it.
Cheers,
Berk
>
>>
>> Mark
>>
>> Thomas and me are also working on multiple end states for
>> lambda-dynamics,
>> but this will still take quite a bit of time until it is finished
>> (not
>> for 5.1 for sure). The additional topology information / topology
>> format
>> expansion should be usable both for free energy methods and
>> lambda-dynamics.
>>
>> Carsten
>>
>>
>> On 26 Nov 2014, at 18:18, Mark Abraham <mark.j.abraham at gmail.com
>> <mailto:mark.j.abraham at gmail.com>> wrote:
>>
>> > Hi,
>> >
>> > It's time we got organized for the next minor release. Generally
>> policy is unchanged - we do a feature-change release at least once a
>> year, and bugfix releases periodically on the last minor/major
>> release. An "extra" release for some special purpose is negotiable.
>> >
>> > I propose
>> >
>> > * now:
>> > + get code you want to be considered for 5.1 into gerrit (tag
>> the first line of the commit message [RFC] or [WIP] if you know that
>> the current state of the code is not a serious candidate for
>> merging)
>> > + get your karma up by participating in review of others'
>> code
>> > + reply to this email (or comment on your patches in gerrit)
>> to guide other people about what might be important for them to
>> review
>> >
>> > * mid-January:
>> > + release 5.0.x
>> > + release 5.1-beta from whatever is the tip of master branch
>> at the time
>> > + fork release-5-1 branch then (still open for functionality
>> changes until the 5.1-rc1 releases; gerrit's feature for cherry
>> picking between branches will make this fork manageable)
>> >
>> > * early-to-mid February:
>> > + release 5.1-rc1
>> > + close release-5-1 to new functionality, it remains open for
>> bug fixes, test cases, and documentation only
>> > + test widely on any plausible machine and compiler for
>> portability and correctness
>> > + release 5.1-rc[234] if that seems like a good idea
>> >
>> > * mid-March:
>> > + release 5.0.x for hopefully the last time, pretty much
>> close release-5-0 branch
>> > + release 5.1
>> > + remove the group cutoff scheme
>> > + ...
>> > + Profit!
>> >
>> > Do speak up if you have a suggestion for a change / request for
>> special consideration / whatever. I've deliberately left the
>> Christmas period open for people who might want to do a last code
>> push at that time, but a huge patch landing without warning on
>> January 10... will probably get ignored by me.
>> >
>> > Please note that things like ongoing contribution with testing
>> and code review are the primary things that might earn an authorship
>> on Gromacs papers (5.0 is still on my TODO list, sorry) - adding
>> some feature is awesome, but what reward structure we can offer
>> needs to focus on the large amount of inglorious work that has to
>> happen.
>> >
>> > Things team Stockholm are actively working on that we'd like to
>> have ready for 5.1 (and the names of the primary people involved)
>> > * new DD communication support (Berk)
>> > * enhancements to pull code (Berk)
>> > * Verlet scheme support for tables, vacuum, Generalized Born
>> (Berk, Alfredo)
>> > * GPU support for tabulated interactions (Alfredo)
>> > * GPU acceleration of (at least) dihedral interactions (Iman)
>> > * combined FFTs for LJ-PME (Christian)
>> > * offload of bonded interactions for enhancing load balance
>> (Mark)
>> > * support for latest CUDA offerings (Szilard)
>> > * OpenCL non-bonded support (mostly Anca from
>> http://www.streamcomputing.eu, Mark)
>> > * support for CPU-based SIMD on everything on the horizon (Erik)
>> >
>> > Like everything else, none of that's going to block releases, but
>> since 5.1 will be the last minor release with the group cutoff
>> scheme, feature completion of the Verlet scheme will be an internal
>> priority for development, review, and testing. Full feature
>> completion is unlikely to happen, so support for twin-range
>> multiple-time stepping, QM/MM, and AdReS may disappear unless people
>> want to put the work in.
>> >
>> > There's a lot of code already in Gerrit awaiting review,
>> particularly from Teemu on the analysis tools. I need to help out
>> more there, but do check if he's fixing stuff that you might care
>> about!
>> >
>> > If you're working on code that you might want to get into 5.1,
>> speak up!
>> >
>> > Happy reviewing!
>> >
>> > Mark
>> > --
>> > Gromacs Developers mailing list
>> >
>> > * Please search the archive
>> athttp://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>> before posting!
>> >
>> > * Can't post? Readhttp://www.gromacs.org/Support/Mailing_Lists
>> >
>> > * For (un)subscribe requests visit
>> >https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org
>> <mailto:gmx-developers-request at gromacs.org>.
>>
>>
>> --
>> Dr. Carsten Kutzner
>> Max Planck Institute for Biophysical Chemistry
>> Theoretical and Computational Biophysics
>> Am Fassberg 11, 37077 Goettingen, Germany
>> Tel. +49-551-2012313 <tel:%2B49-551-2012313>, Fax: +49-551-2012302
>> <tel:%2B49-551-2012302>
>> http://www.mpibpc.mpg.de/grubmueller/kutzner
>> http://www.mpibpc.mpg.de/grubmueller/sppexa
>>
>> --
>> Gromacs Developers mailing list
>>
>> * Please search the archive at
>> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List
>> before posting!
>>
>> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>>
>> * For (un)subscribe requests visit
>> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
>> or send a mail to gmx-developers-request at gromacs.org
>> <mailto:gmx-developers-request at gromacs.org>.
>>
>>
>>
>>
>
>
More information about the gromacs.org_gmx-developers
mailing list