[gmx-developers] Re: 4.6.1 soon!

[Szilárd Páll]

On Wed, Feb 20, 2013 at 4:52 AM, Christoph Junghans <junghans at votca.org>wrote:

> 2013/2/19 Mark Abraham <mark.j.abraham at gmail.com>:
> >
> >
> > On Tue, Feb 19, 2013 at 5:30 PM, Christoph Junghans <junghans at votca.org>
> > wrote:
> >>
> >> 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 ;-)
> >
> >
> > Understood :-)
> >
> > There's no embargo. If someone says they've fixed OpenMM to work from
> > contrib, then the code will get reviewed and presumably get merged after
> due
> > process. There just won't be Stockholm people spending significant time
> on
> > it :-)
> >
> >> > 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/>)
> b.) is done: <https://gerrit.gromacs.org/#/c/2087/6>
> and one doesn't even need to uncomment the option -DGMX_OPENMM=ON
> works either way.
>

Thanks, I guess I owe you one.

Does it work without having to manually turn MPI, thread-MPI, OpenMP etc
off? That's what broke when the original setup/consistency check code was
moved from /CMakeLists.txt to /src/contrib/CMakeLists.txt.

Additionally, I'll try to find 10 minutes of time to remove the
device-specific check and warning and simply allow any device that OpenMM
supports. This way we won't issue annoying warning on new GPUs not in the
list.

Any idea if the new OpenMM 4 works? Bsed on the release notes and the new
paper it should be considerably faster than previous versions - which IMO
is worth a little developer time as our native GB code is still rather
borked.

Cheers,
--
Szilárd



>
> >> 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)
> >
> >
> > I'm happy with:
> >
> > a) and walk away
> > a) and do minimal work on b) for 4.6.2 (4.6.1 freeze is already past; I'd
> > have shipped a tarball whenever the code gets reviewed already :-))
> > b) for 4.6.2
> > c) if it's possible to do that, sure (then, ideally, b) for 4.6.2)
> >
> > IMO there's only cosmetic value in d.
> >
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20130301/5ae4d8c3/attachment.html>