<div dir="ltr"><div class="gmail_extra"><div><div>On Thu, Mar 10, 2016 at 5:41 PM, Mark Abraham <span dir="ltr"><<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>></span> wrote:<br></div></div><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 dir="ltr">Hi,<br><br><div class="gmail_quote"><span><div dir="ltr">On Thu, Mar 10, 2016 at 4:56 PM Szilárd Páll <<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>> wrote:<br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 9, 2016 at 4:43 PM, Mark Abraham <span dir="ltr"><<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>></span> wrote:<br></div></div></div><div dir="ltr"><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 dir="ltr">Hi,<div><br></div><br></div></blockquote></div></div></div><div dir="ltr"><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 dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Wed, Mar 9, 2016 at 3:42 PM Szilárd Páll <<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>> wrote:<br></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 dir="ltr">Hi,<div><br></div><div>No, I don't. I triggered it the other day because I did not know the main 5.1 matrix does the job already.</div></div></blockquote><div><br></div></span><div>OK, I'll delete it tomorrow.</div><span><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 dir="ltr"><div>What about master, additional releng support is needed I guess? Also, is there anything holding us back from adding pre- and post-submit configs to admin//builds/*matrix.txt.</div></div></blockquote><div><br></div></span><div>See my other email to gmx-developers just now. I think pre-submit should cover only the highest-value targets. Post-submit for lower-value targets and/or tests that take more time.</div></div></div></blockquote></div></div></div><div dir="ltr"><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 dir="ltr"></div></blockquote><div><br></div><div>I agree. A dozen or so configs to cover the most common software/parallelization configurations should be enough. Having looked at the Gromacs_Gerrit_master_nrwpo configs,</div></div></div></div></blockquote><div><br></div></span><div>Don't, that's just an example set so people can run a custom config if they have a need to do so. I have now clarified that in the Jenkins parameter description text. Per my other email, the matrix lives in the source repo at admin/builds/pre-submit-matrix.txt</div><span><div><br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> I propose the following additions/tweaks:</div><div>- OpenCL (I suggest using AMD GPUs and adding both release and debug, error handling is rather poor and OpenCL API erros are mostly handled with assert's)</div></div></div></div></blockquote><div><br></div></span><div>Sure, but first we have to make the build work (there were mysterious failures last time I tried it).</div></div></div></blockquote><div><br></div><div>Let me know if I can help with debugging them - especially if they are GROMACS failures rather than infrastructure failures.</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 dir="ltr"><div class="gmail_quote"><span><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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- an SSE4.1 (i.e. 4-wide SIMD) build unless - AFAICT VM-based builds are not already doing that;</div></div></div></div></blockquote><div><br></div></span><div>Plausible, but why is it a "highest-value target?" That and SSE2 seem like candidates for post-submit testing. If some patch fails to break other kinds of SIMD, it's pretty unlikely to break precisely these, unless the patch is somehow aimed at them.</div></div></div></blockquote><div><br></div><div>Because with AVX we'd have only 8-wide SIMD and algorithmically (at for nbnxn, but not only) 4-wide SIMD is a relevant target.</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 dir="ltr"><div class="gmail_quote"><span><div><br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>- some runs that execute tests with 2D/3D DD (if 3D is hw resource-wise an issue could be left for post-submit),</div></div></div></div></blockquote><div><br></div></span><div>I don't remember whether this still happens automagically. Running some multi-rank tests seems wise, but yeah 3D can probably take a lower priority if 2D is covered.</div></div></div></blockquote><div><br></div><div>Sure. 3D will require 8 ranks at least, but given that we have 2x32 mostly idle hypervisor cores, even that's not a resource limitation.</div><div><br></div><div>+ separate PME ranks is what I forgot. With 1-2 PP + 1 PME that only requires 3 ranks.</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 dir="ltr"><div class="gmail_quote"><span><div><br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Additionally:</div>- Has valgrind testing been discontinued? (Teemu mentioned on #1815 that valgrind configs got accidentally removed at some point?) <br></div></div></div></blockquote></span><div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">AFAICR it's currently disabled with at least Windows, icc, gcc-5 and clang builds, for issues including those caused by</div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px"><a href="http://valgrind.org/docs/manual/faq.html#faq.reports" target="_blank">http://<span>valgrind</span>.org/docs/manual/faq.html#faq.reports</a></div><div style="font-size:13px;line-height:19.5px"><a href="https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.memory" target="_blank">https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.memory</a><br></div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">If we want to use it in Jenkins in future, then I think we need to commit to running it with a C++ standard library in "always free memory mode," which is going to be even slower to run and/or harder to maintain on "real" build slaves. <span>Valgrind</span> is approximately superseded by MemorySanitizer, for which we have a build type and a probably-not-badly-broken build at <a href="http://jenkins.gromacs.org/job/Gromacs_Gerrit_master-test-MSan/" target="_blank">http://jenkins.gromacs.org/job/Gromacs_Gerrit_master-test-MSan/</a>. These kinds of tools are particularly brittle with respect to dependencies, etc. so I think they make sense to run regularly in Jenkins only if we implement them in a Docker environment, built with a script (Google suggests some people might have done this for us already), rather than on some build slave whose setup details nobody can remember and will break upon upgrades :-)</div></div></div></div></blockquote><div><br></div><div>Thanks. Makes sense, although I'm not sure how does Docker improve things besides forcing one to "document" the installation/setup?</div><div><br></div><div>--<br>Szilárd<br></div><div><br></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 dir="ltr"><div class="gmail_quote"><span><div><br></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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote">- How about TSAN? I've seen no confgis use it (but we've been using it for 5.1, right?)</div></div></div></blockquote><div><br></div></span><div>It's in the actual matrix already. In the longer term, I think it also makes sense on a Docker image.</div><span><font color="#888888"><div><br></div><div>Mark</div></font></span></div></div>
<br>--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br></blockquote></div><br></div></div>