<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 18, 2013 at 6:47 PM, Roland Schulz <span dir="ltr"><<a href="mailto:roland@utk.edu" target="_blank">roland@utk.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Jun 18, 2013 at 11:05 AM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>> wrote:<br>
<div><div class="h5">><br>
><br>
><br>
> On Mon, Jun 17, 2013 at 7:59 PM, Roland Schulz <<a href="mailto:roland@utk.edu">roland@utk.edu</a>> wrote:<br>
>><br>
>> On Mon, Jun 17, 2013 at 1:10 PM, Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com">mark.j.abraham@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Jun 17, 2013 at 6:16 PM, Manuel Nuno Melo <<a href="mailto:m.n.melo@rug.nl">m.n.melo@rug.nl</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Hi,<br>
>> >><br>
>> >> I have also had linking problems when making in parallel. In my case<br>
>> >> they<br>
>> >> could be traced back to the option to let GMX download/build its own<br>
>> >> fftw<br>
>> >> (-DGMX_BUILD_OWN_FFTW=ON).<br>
>> >><br>
>> >> It seems that only one of make's threads starts building fftw, while<br>
>> >> the<br>
>> >> others go ahead building/linking GMX. Since fftw compilation is not<br>
>> >> ready by<br>
>> >> the time it is needed, GMX linking is botched.<br>
>> ><br>
>> ><br>
>> > Yes, Rossen first showed this to me. I don't know if the underlying<br>
>> > issue is<br>
>> > that the dependency cannot be described properly, or that we're not<br>
>> > doing it<br>
>> > properly. If it's a problem, people are welcome to contribute a fix! :-)<br>
>> It was working in <a href="https://gerrit.gromacs.org/#/c/1675/12" target="_blank">https://gerrit.gromacs.org/#/c/1675/12</a>. You then<br>
>> changed how the dependency works in patch set 13. You never replied to<br>
>> Christophs comment why this was changed (at least I can't find a<br>
>> reply). Do you remember?<br>
><br>
><br>
</div></div><div class="im">> I couldn't remember, but gerrit can - I never published a series of<br>
> responses I made back then, sorry. Now published at<br>
> <a href="https://gerrit.gromacs.org/1675" target="_blank">https://gerrit.gromacs.org/1675</a><br>
><br>
</div><div class="im">>> Otherwise I can change it back as 12 did it<br>
>> and it should work again.<br>
><br>
><br>
</div><div class="im">> It might do, but as I said in those secret drafts the form of patch 12<br>
> doesn't work on cmake 2.8.7 because of a bug there in add_library(...GLOBAL)<br>
> (and I suspect is probably too global, anyway, but this probably does no<br>
> harm?).<br>
><br>
> So I'm still not sure there's a convenient solution that works in all cases.<br>
> Compromising the smooth running of a parallel make for someone downloading<br>
> FFTW seems like the most low-impact problem of the set we could choose to<br>
> have.<br>
<br>
</div>Probably true. Just doesn't give a good first impression of us to new users.<br>
I think we should also consider for the future whether we really want<br>
to support ~11 unmaintained version of cmake (including for all our<br>
optional features). Downloading cmake is no big deal. They have<br>
binaries to download. And cmake doesn't fix any version but for the<br>
most recent version. So it seems odd that we try to maintain<br>
workarounds for the last ~11 versions which are all unmaintained by<br>
the cmake developers. That seems like it is going to stay a really<br>
annoying maintenance task.<br></blockquote><div><br></div><div style>True. Now that we've shown it is a PITA for the developers to work around a handful of known issues with various 2.8.x point releases of CMake, it sounds reasonable to me that we pick a late-model CMake 2.8.x as the requirement for GROMACS 5. That could open the door to an alternative implementation for self-built FFTW.</div>
<div style><br></div><div style>Mark</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Roland<br>
<br>
<br>
><br>
> Mark<br>
<div class="HOEnZb"><div class="h5">><br>
>><br>
>> Roland<br>
>><br>
>> ><br>
>> > Mark<br>
>> ><br>
>> >><br>
>> >><br>
>> >> Cheers,<br>
>> >> Manel<br>
>> >><br>
>> >> > Hi,<br>
>> >> ><br>
>> >> > I too suspect filesystem issues or clock skews. I think I tested make<br>
>> >> > -j<br>
>> >> > and make -j 12. The cluster is currently down for maintenance, so I<br>
>> >> > can't<br>
>> >> > inspect the details at the moment.<br>
>> >> ><br>
>> >> > On 5 Apr 2013, at 13:14, Alexey Shvetsov <alexxy at <a href="http://omrb.pnpi.spb.ru" target="_blank">omrb.pnpi.spb.ru</a>><br>
>> >> > wrote:<br>
>> >> ><br>
>> >> > > Hi Erik<br>
>> >> > ><br>
>> >> > > What are underlaying filesystem on this cluster? If it slow or<br>
>> >> > > overloaded<br>
>> >> > > somehow it may lead to parallel make issues. Also it may be related<br>
>> >> > > to<br>
>> >> > > make<br>
>> >> > > version (some old versions may expose such behavior). How many make<br>
>> >> > > threads do<br>
>> >> > > you issued? I tryed with make -j64 and it builds fine with recent<br>
>> >> > > cmake<br>
>> >> > > (2.8.10) and make (3.82) utility.<br>
>> >> > ><br>
>> >> > ><br>
>> >> > > ÷ ÐÉÓØÍÅ ÏÔ 5 ÁÐÒÅÌÑ 2013 11:55:27 ÐÏÌØÚÏ×ÁÔÅÌØ Erik Marklund<br>
>> >> > > ÎÁÐÉÓÁÌ:<br>
>> >> > >> Hi,<br>
>> >> > >><br>
>> >> > >> Building gromacs 4.6.1 failed whenever I issued parallel make,<br>
>> >> > >> i.e.<br>
>> >> > >> make -j.<br>
>> >> > >> I reported this to the cluster admins since I had never seen such<br>
>> >> > >> behaviour<br>
>> >> > >> before from gromacs' side, and here's their reply. I can't tell<br>
>> >> > >> whether<br>
>> >> > >> gromacs is at fault or the cluster.<br>
>> >> > >><br>
>> >> > >> Erik<br>
>> >> > >><br>
>> >> > >> Begin forwarded message:<br>
>> >> > >>> Hi,<br>
>> >> > >>><br>
>> >> > >>>> I was compiling gromacs on tintin's login node the other day and<br>
>> >> > >>>> it<br>
>> >> > >>>><br>
>> >> > >>>> šseems that parallel make, i.e. make -j, doesn't work on tintin.<br>
>> >> > >>>> I<br>
>> >> > >>>> šgot linker errors that never showed up when make was run<br>
>> >> > >>>> serially.<br>
>> >> > >>>> šI've never encountered such behaviour before.<br>
>> >> > >>><br>
>> >> > >>> Without any more information (or being able to look for actual<br>
>> >> > >>> files<br>
>> >> > >>> right<br>
>> >> > >>> now), I'd guess this is a problem with the makefiles rather than<br>
>> >> > >>> the<br>
>> >> > >>> actual make. It seems somewhat unexpected that CMake would create<br>
>> >> > >>> makefiles that aren't safe for parallel building, but it does<br>
>> >> > >>> seem<br>
>> >> > >>> the<br>
>> >> > >>> most likely culprit (assuming it doesn't let developers add rules<br>
>> >> > >>> directly to the makefile to work around problems, I don't<br>
>> >> > >>> remember<br>
>> >> > >>> if<br>
>> >> > >>> that's possible).<br>
>> >> > >>><br>
>> >> > >>> That you only see the problem on tintin can likely be explained<br>
>> >> > >>> by<br>
>> >> > >>> timing<br>
>> >> > >>> or other non deterministic factors.<br>
>> >> > > --<br>
>> >> > > Best Regards,<br>
>> >> > > Alexey 'Alexxy' Shvetsov<br>
>> >><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>
>> ><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>
>> 865-241-1537, ORNL PO BOX 2008 MS6309<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>
><br>
><br>
<br>
<br>
<br>
--<br>
ORNL/UT Center for Molecular Biophysics <a href="http://cmb.ornl.gov" target="_blank">cmb.ornl.gov</a><br>
865-241-1537, ORNL PO BOX 2008 MS6309<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>