[gmx-developers] Re: 4.6.1 soon!

Christoph Junghans junghans at votca.org
Tue Feb 19 17:30:51 CET 2013 

2013/2/19 Mark Abraham <mark.j.abraham at gmail.com>:
>
>
> On Tue, Feb 19, 2013 at 4:02 AM, Christoph Junghans <junghans at votca.org>
> wrote:
>>
>> 2013/2/18 Mark Abraham <mark.j.abraham at gmail.com>:
>> >
>> >
>> > On Mon, Feb 18, 2013 at 8:39 PM, Christoph Junghans <junghans at votca.org>
>> > wrote:
>> >>
>> >> 2013/2/18 Berk Hess <hess at kth.se>:
>> >> > Hi,
>> >> >
>> >> > I fully agree.
>> >> > Since OpenMM is not fully supported 6.1.12 should be removed from the
>> >> > manual.
>> >> Apropos OpenMM, currently there are some directory offsets wrong in
>> >> the build system, which make it practically impossible to enable the
>> >> OpenMM support:
>> >> <https://gerrit.gromacs.org/#/c/2087/>
>> >> A fix should go into 4.6.1. The above change set is not complete yet
>> >> as some CMAKE_CXX variables are missing.
>> I guess, we just need to enable CXX, before the compiler checks to fix
>> the above issue, but then we would have an openmm conditional in main
>> cmakelists.txt file, which is also not nice.
>> >
>> >
>> > I looked at that patch last week, and it seemed to me like there was not
>> > much consensus about what solution was appropriate. I thought we'd
>> > probably
>> > not reach an acceptable solution in time for 4.6.1. Thus it's not in the
>> > list of commits I plan for 4.6.1. The choice of commits and timing for a
>> > release is normally pretty arbitrary, but there has to be one or we
>> > never
>> > deliver anything!
>> I like to have deadlines, but that also means we have to find a
>> consensus in time and not just ignore things.
>> As far as I can see only Szilard had an opinion on that issue.
>
>
> When resources are finite, things get deferred. I'm our only full-time
> resource on this project. Everybody else is some degree of volunteer. It's
> great that we have such willing, capable and dedicated volunteers, but we
> all have to prioritise our time. I know I could keep two clones of me busy
> :-)
To clarify, I don't ask you to fix it, I will take care of it as soon
as we have decided on something, I just don't want to waste my time
fixing it if the patch doesn't get merged in the end ;-)

>
> In the case of things in contrib, that deferral might in practice be
> infinite. That's life. There's 170 open Redmine issues needing attention :-)
>
>> > If fixing OpenMM to build and/or work from src/contrib is important to
>> > someone, then they're welcome to spend some time on it. Frankly, there's
>> > not
>> > much of value in 4.6 that will also benefit someone who needs an
>> > OpenMM-capable mdrun. If I needed the latter, I'd be installing a 4.5.x
>> > version of GROMACS for OpenMM and hoping for the best!
>> >
>> > I'd be perfectly happy removing it entirely from the repo. One of the
>> > joys
>> > of version control is that it is easy to revert the deletion patch.
>> I haven't heard any complains on the user's list, so I guess removing
>> it would be the easiest, quickest and cleanest solution, but Szilard
>> had the opposite opinion. In the current state nobody will realize
>> when md_openmm.c and normal md.c get out of sync as it is hard to
>> build in the first place,  it is just a matter of time until openmm
>> support gets completely broken.
>
>
> Yep. It's in contrib so it's clear we're not maintaining it. There's
> probably other stuff that will join it later in the year. Ideally, stuff in
> contrib would work, rather than be a dumping ground, but that requires
> maintenance and testing and we're not prepared to do that for things we've
> put in contrib. Two months elapsed after people in Stockholm decided they
> didn't want to maintain it, so I took the initiative to move it to where
> that decision was clear to the wider team. Another month has passed. If
> nobody wants to make it work or maintain it there, then it will quietly die.
>
> An alternative would be to create a "feature" branch that labels the "last
> believed good" version of code before we decide to stop supporting it &
> remove its code. That's just going to be a label on a commit. The same
> purpose is served by looking at the parent of the commit before a feature's
> code was moved to contrib.
The only reason why I am pushing for a fix is that, right now, one
cold get the impression that uncommenting a single line in
src/contrib/CMakeLists.txt would be enough to build OpenMM, which is
not the case.

I guess we have 4 solutions:
a.) change the comment in src/contrib/CMakeLists.txt
b.) fix it for 4.6.1 or 4.6.2 (90% done in
<https://gerrit.gromacs.org/#/c/2087/>)
c.) remove OpenMM reference from everywhere, but src/contrib to make
it 100% contrib (will take me 5 mins to create a patch)
d.) feature branch (+c.) in release-4-6 branch)

So, please developers speak up.

Christoph

>
> Mark
>
>>
>>
>> Christoph
>>
>> >
>> > Mark
>> >
>> >>
>> >> Cheers,
>> >>
>> >> Christoph
>> >>
>> >>
>> >> > Are there any other issues with the manual you know of?
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Berk
>> >> >
>> >> >
>> >> > On 02/18/2013 02:18 PM, Justin Lemkul wrote:
>> >> >>
>> >> >>
>> >> >> Hi All,
>> >> >>
>> >> >> I'm assuming fixes to the manual are being considered separately
>> >> >> then?
>> >> >> To
>> >> >> me, we really shouldn't release 4.6.1 unless we have a corresponding
>> >> >> manual
>> >> >> out at least within 24 hr of the code being made public.  In my
>> >> >> mind,
>> >> >> released code necessitates a definitive manual, and there have been
>> >> >> questions on the user list related to the manual.  There are still
>> >> >> some
>> >> >> glaring inaccuracies and outdated information, mostly in section
>> >> >> 6.12
>> >> >> related to GPU usage (basically it needs to be scrapped, since
>> >> >> OpenMM
>> >> >> isn't
>> >> >> even fully supported any more) and Appendix A. My patch related to
>> >> >> environment variables (https://gerrit.gromacs.org/#/c/2055/) is
>> >> >> basically
>> >> >> done since Szilard finished off the last few items, but hasn't even
>> >> >> been
>> >> >> reviewed.
>> >> >>
>> >> >> -Justin
>> >> >>
>> >> >> On 2/18/13 8:07 AM, Mark Abraham wrote:
>> >> >>>
>> >> >>> Hi GROMACS developers,
>> >> >>>
>> >> >>> There's a release branch constructed, containing a number of minor
>> >> >>> fixes,
>> >> >>> documentation updates and a few remaining fixes of critical issues.
>> >> >>> Below
>> >> >>> is a
>> >> >>> list of commits that are ancestors of the 4.6.1 release patch -
>> >> >>> please
>> >> >>> review
>> >> >>> things that you know about!
>> >> >>>
>> >> >>> https://gerrit.gromacs.org/#q,I60998e3b,n,z New patch release 4.6.1
>> >> >>> https://gerrit.gromacs.org/#q,I9a551260,n,z Update outdated admin
>> >> >>> things
>> >> >>> https://gerrit.gromacs.org/#q,Iba5b4c66,n,z Fixes for install guide
>> >> >>> page.
>> >> >>> https://gerrit.gromacs.org/#q,Ia0a571d2,n,z Updated install guide
>> >> >>> https://gerrit.gromacs.org/#q,I33495d57,n,z Uncrustified code
>> >> >>> changes
>> >> >>> since 4.6
>> >> >>> https://gerrit.gromacs.org/#q,If96fd044,n,z Bump shared object
>> >> >>> version
>> >> >>> to
>> >> >>> 8
>> >> >>> https://gerrit.gromacs.org/#q,I79a06b20,n,z fixed issues with FEP
>> >> >>> soft-core and
>> >> >>> cut-off's
>> >> >>> https://gerrit.gromacs.org/#q,Ib90ac4e5,n,z Merge
>> >> >>> release-4-5-patches
>> >> >>> into
>> >> >>> release-4-6
>> >> >>> https://gerrit.gromacs.org/#q,I146592c3,n,z fixed GPU particle
>> >> >>> gridding
>> >> >>> performance issue
>> >> >>> https://gerrit.gromacs.org/#q,I268bbf65,n,z Made g_tune_pme work
>> >> >>> with
>> >> >>> 4.6
>> >> >>> if
>> >> >>> user sets "-p" command line option
>> >> >>> https://gerrit.gromacs.org/#q,I79fd46e1,n,z Fix CMake namespace
>> >> >>> pollution
>> >> >>> https://gerrit.gromacs.org/#q,I3c37844c,n,z Issue errors/warnings
>> >> >>> for
>> >> >>> ICC
>> >> >>> before
>> >> >>> 12.0.0
>> >> >>> https://gerrit.gromacs.org/#q,Ia6157db8,n,z bugfix for md-vv +
>> >> >>> nose-hoover +
>> >> >>> (nstcalcenergy > nsttcouple)
>> >> >>> https://gerrit.gromacs.org/#q,Ia071c6a1,n,z Use explicit kernel
>> >> >>> pointer
>> >> >>> typecasts
>> >> >>>
>> >> >>> Mark
>> >> >>>
>> >> >>> On Tue, Feb 12, 2013 at 9:15 PM, Mark Abraham
>> >> >>> <mark.j.abraham at gmail.com
>> >> >>> <mailto:mark.j.abraham at gmail.com>> wrote:
>> >> >>>
>> >> >>>     Hi GROMACS developers,
>> >> >>>
>> >> >>>     We've made a number of bug fixes to 4.6, and it's time we got
>> >> >>> those
>> >> >>> out to
>> >> >>>     the world in 4.6.1. There's a few bits and pieces still sitting
>> >> >>> in
>> >> >>> gerrit,
>> >> >>>     so please see what you can get done. I'll plan to construct a
>> >> >>> release
>> >> >>> branch
>> >> >>>     on Friday and release Monday Feb 17.
>> >> >>>
>> >> >>>     Cheers,
>> >> >>>
>> >> >>>     Mark
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >> > --
>> >> > gmx-developers mailing list
>> >> > gmx-developers at gromacs.org
>> >> > 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 at gromacs.org.
>> >>
>> >>
>> >>
>> >> --
>> >> Christoph Junghans
>> >> Web: http://www.compphys.de
>> >> --
>> >> gmx-developers mailing list
>> >> gmx-developers at gromacs.org
>> >> 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 at gromacs.org.
>> >
>> >
>> >
>> > --
>> > gmx-developers mailing list
>> > gmx-developers at gromacs.org
>> > 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 at gromacs.org.
>>
>>
>>
>> --
>> Christoph Junghans
>> Web: http://www.compphys.de
>> --
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> 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 at gromacs.org.
>
>
>
> --
> gmx-developers mailing list
> gmx-developers at gromacs.org
> 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 at gromacs.org.



--
Christoph Junghans
Web: http://www.compphys.de

More information about the gromacs.org_gmx-developers mailing list