<div dir="ltr">On Wed, Feb 20, 2013 at 4:52 AM, Christoph Junghans <span dir="ltr"><<a href="mailto:junghans@votca.org" target="_blank">junghans@votca.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">2013/2/19 Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>>:<br>
><br>
><br>
> On Tue, Feb 19, 2013 at 5:30 PM, Christoph Junghans <<a href="mailto:junghans@votca.org">junghans@votca.org</a>><br>
> wrote:<br>
>><br>
>> 2013/2/19 Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>>:<br>
>> ><br>
>> ><br>
>> > On Tue, Feb 19, 2013 at 4:02 AM, Christoph Junghans <<a href="mailto:junghans@votca.org">junghans@votca.org</a>><br>
>> > wrote:<br>
>> >><br>
>> >> 2013/2/18 Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>>:<br>
>> >> ><br>
>> >> ><br>
>> >> > On Mon, Feb 18, 2013 at 8:39 PM, Christoph Junghans<br>
>> >> > <<a href="mailto:junghans@votca.org">junghans@votca.org</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> 2013/2/18 Berk Hess <<a href="mailto:hess@kth.se">hess@kth.se</a>>:<br>
>> >> >> > Hi,<br>
>> >> >> ><br>
>> >> >> > I fully agree.<br>
>> >> >> > Since OpenMM is not fully supported 6.1.12 should be removed from<br>
>> >> >> > the<br>
>> >> >> > manual.<br>
>> >> >> Apropos OpenMM, currently there are some directory offsets wrong in<br>
>> >> >> the build system, which make it practically impossible to enable the<br>
>> >> >> OpenMM support:<br>
>> >> >> <<a href="https://gerrit.gromacs.org/#/c/2087/" target="_blank">https://gerrit.gromacs.org/#/c/2087/</a>><br>
>> >> >> A fix should go into 4.6.1. The above change set is not complete yet<br>
>> >> >> as some CMAKE_CXX variables are missing.<br>
>> >> I guess, we just need to enable CXX, before the compiler checks to fix<br>
>> >> the above issue, but then we would have an openmm conditional in main<br>
>> >> cmakelists.txt file, which is also not nice.<br>
>> >> ><br>
>> >> ><br>
>> >> > I looked at that patch last week, and it seemed to me like there was<br>
>> >> > not<br>
>> >> > much consensus about what solution was appropriate. I thought we'd<br>
>> >> > probably<br>
>> >> > not reach an acceptable solution in time for 4.6.1. Thus it's not in<br>
>> >> > the<br>
>> >> > list of commits I plan for 4.6.1. The choice of commits and timing<br>
>> >> > for a<br>
>> >> > release is normally pretty arbitrary, but there has to be one or we<br>
>> >> > never<br>
>> >> > deliver anything!<br>
>> >> I like to have deadlines, but that also means we have to find a<br>
>> >> consensus in time and not just ignore things.<br>
>> >> As far as I can see only Szilard had an opinion on that issue.<br>
>> ><br>
>> ><br>
>> > When resources are finite, things get deferred. I'm our only full-time<br>
>> > resource on this project. Everybody else is some degree of volunteer.<br>
>> > It's<br>
>> > great that we have such willing, capable and dedicated volunteers, but<br>
>> > we<br>
>> > all have to prioritise our time. I know I could keep two clones of me<br>
>> > busy<br>
>> > :-)<br>
>> To clarify, I don't ask you to fix it, I will take care of it as soon<br>
>> as we have decided on something, I just don't want to waste my time<br>
>> fixing it if the patch doesn't get merged in the end ;-)<br>
><br>
><br>
> Understood :-)<br>
><br>
> There's no embargo. If someone says they've fixed OpenMM to work from<br>
> contrib, then the code will get reviewed and presumably get merged after due<br>
> process. There just won't be Stockholm people spending significant time on<br>
> it :-)<br>
><br>
>> > In the case of things in contrib, that deferral might in practice be<br>
>> > infinite. That's life. There's 170 open Redmine issues needing attention<br>
>> > :-)<br>
>> ><br>
>> >> > If fixing OpenMM to build and/or work from src/contrib is important<br>
>> >> > to<br>
>> >> > someone, then they're welcome to spend some time on it. Frankly,<br>
>> >> > there's<br>
>> >> > not<br>
>> >> > much of value in 4.6 that will also benefit someone who needs an<br>
>> >> > OpenMM-capable mdrun. If I needed the latter, I'd be installing a<br>
>> >> > 4.5.x<br>
>> >> > version of GROMACS for OpenMM and hoping for the best!<br>
>> >> ><br>
>> >> > I'd be perfectly happy removing it entirely from the repo. One of the<br>
>> >> > joys<br>
>> >> > of version control is that it is easy to revert the deletion patch.<br>
>> >> I haven't heard any complains on the user's list, so I guess removing<br>
>> >> it would be the easiest, quickest and cleanest solution, but Szilard<br>
>> >> had the opposite opinion. In the current state nobody will realize<br>
>> >> when md_openmm.c and normal md.c get out of sync as it is hard to<br>
>> >> build in the first place, it is just a matter of time until openmm<br>
>> >> support gets completely broken.<br>
>> ><br>
>> ><br>
>> > Yep. It's in contrib so it's clear we're not maintaining it. There's<br>
>> > probably other stuff that will join it later in the year. Ideally, stuff<br>
>> > in<br>
>> > contrib would work, rather than be a dumping ground, but that requires<br>
>> > maintenance and testing and we're not prepared to do that for things<br>
>> > we've<br>
>> > put in contrib. Two months elapsed after people in Stockholm decided<br>
>> > they<br>
>> > didn't want to maintain it, so I took the initiative to move it to where<br>
>> > that decision was clear to the wider team. Another month has passed. If<br>
>> > nobody wants to make it work or maintain it there, then it will quietly<br>
>> > die.<br>
>> ><br>
>> > An alternative would be to create a "feature" branch that labels the<br>
>> > "last<br>
>> > believed good" version of code before we decide to stop supporting it &<br>
>> > remove its code. That's just going to be a label on a commit. The same<br>
>> > purpose is served by looking at the parent of the commit before a<br>
>> > feature's<br>
>> > code was moved to contrib.<br>
>> The only reason why I am pushing for a fix is that, right now, one<br>
>> cold get the impression that uncommenting a single line in<br>
>> src/contrib/CMakeLists.txt would be enough to build OpenMM, which is<br>
>> not the case.<br>
>><br>
>> I guess we have 4 solutions:<br>
>> a.) change the comment in src/contrib/CMakeLists.txt<br>
>> b.) fix it for 4.6.1 or 4.6.2 (90% done in<br>
>> <<a href="https://gerrit.gromacs.org/#/c/2087/" target="_blank">https://gerrit.gromacs.org/#/c/2087/</a>>)<br>
</div></div>b.) is done: <<a href="https://gerrit.gromacs.org/#/c/2087/6" target="_blank">https://gerrit.gromacs.org/#/c/2087/6</a>><br>
and one doesn't even need to uncomment the option -DGMX_OPENMM=ON<br>
works either way.<br></blockquote><div><br></div><div style>Thanks, I guess I owe you one. </div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style><br></div><div style>Cheers,<br class="">--<br>Szilárd<br></div><div style><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
>> c.) remove OpenMM reference from everywhere, but src/contrib to make<br>
>> it 100% contrib (will take me 5 mins to create a patch)<br>
>> d.) feature branch (+c.) in release-4-6 branch)<br>
><br>
><br>
> I'm happy with:<br>
><br>
> a) and walk away<br>
> a) and do minimal work on b) for 4.6.2 (4.6.1 freeze is already past; I'd<br>
> have shipped a tarball whenever the code gets reviewed already :-))<br>
> b) for 4.6.2<br>
> c) if it's possible to do that, sure (then, ideally, b) for 4.6.2)<br>
><br>
> IMO there's only cosmetic value in d.<br>
><br>
> Mark<br>
><br>
><br>
</div><div class=""><div class="h5">> --<br>
> gmx-developers mailing list<br>
> <a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
> <a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
> Please don't post (un)subscribe requests to the list. Use the<br>
> www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
<br>
<br>
<br>
--<br>
Christoph Junghans<br>
Web: <a href="http://www.compphys.de" target="_blank">http://www.compphys.de</a><br>
--<br>
gmx-developers mailing list<br>
<a href="mailto:gmx-developers@gromacs.org">gmx-developers@gromacs.org</a><br>
<a href="http://lists.gromacs.org/mailman/listinfo/gmx-developers" target="_blank">http://lists.gromacs.org/mailman/listinfo/gmx-developers</a><br>
Please don't post (un)subscribe requests to the list. Use the<br>
www interface or send it to <a href="mailto:gmx-developers-request@gromacs.org">gmx-developers-request@gromacs.org</a>.<br>
</div></div></blockquote></div><br></div></div>