<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 2, 2018 at 12:58 PM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Adrián Amor <<a href="mailto:aamor@pa.uc3m.es">aamor@pa.uc3m.es</a>> writes:<br>
<br>
> 1. I have compiled PETSC with these options:<br>
> ./configure --with-cc=mpiicc --with-cxx=mpiicpc --with-fc=mpiifort<br>
> --with-blas-lapack-dir=/opt/<wbr>intel/mkl/lib/intel64/ --with-debugging=1<br>
> --with-scalar-type=complex --with-threadcomm --with-pthreadclasses<br>
> --with-openmp<br>
> --with-openmp-include=/opt/<wbr>intel/compilers_and_libraries_<wbr>2016.1.150/linux/compiler/lib/<wbr>intel64_lin<br>
> --with-openmp-lib=/opt/intel/<wbr>compilers_and_libraries_2016.<wbr>1.150/linux/compiler/lib/<wbr>intel64_lin/libiomp5.a<br>
<br>
Matt, --with-threadcomm and --with-pthreadclasses were removed in 2015,<br>
but people still use these options and think they are doing something<br>
because configure doesn't even mention unused options.  We've been<br>
talking about fixing this for at least a decade, and yet here we still<br>
are.  Things like this get fixed in the C code, so it can't be pure<br>
laziness.  Python is supposed to be easy, but this part of BuildSystem<br>
is evidently scary.  I have no idea if fixing this would be a 2-hour job<br>
or if it would snowball into more than 20.  It's hard to estimate time<br>
to make cross-cutting changes, but in my experience, BuildSystem is<br>
especially hard to make estimates about.  I spent an hour or two trying<br>
to assess this particular issue and came up empty-handed some years ago.<br>
I've had several other false starts over the years, trying to make minor<br>
improvements to BuildSystem and finding a web of subtle dependencies.<br>
The PETSc library tends to have well-documented interfaces with minimal<br>
side-effects, but BuildSystem has a lot of similarly-named undocumented<br>
(or inaccurately-documented) interfaces with implications that are hard<br>
to reason about.  I don't have an immediate solution, but this technical<br>
debt is costly.  It works, in many ways functionally better than<br>
alternatives, but it's really hard to work on.<br>
</blockquote></div><br>I guess my superficial response to this is</div><div class="gmail_extra"><br></div><div class="gmail_extra">  a) I do not consider Buildsystem "mine" anymore. I may still have the most lines of code, but I am not even sure of that.</div><div class="gmail_extra">      However, I am interested in fixing problems, since I think it is still the best available way to do these things.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  b) Broad criticisms are very useful as a way to introduce specific criticisms that can be worked on. Divorced from that</div><div class="gmail_extra">      grounding, they are much less useful.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  c) I believe that you have a hard time making modifications. I would note that this code has received a steady stream of</div><div class="gmail_extra">      updates for its entire existence, so it is not impossible, but perhaps too hard.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  d) The particular problem you bring up is not that hard (I think) to fix. You go into RDict, which is the place where all options</div><div class="gmail_extra">       are held. Put in a marker which gets set when the option is accessed, just as we do in PETSc. The problem is really</div><div class="gmail_extra">       that configure is likely to produce many more false positives, as people often put in things that might not be accessed.</div><div class="gmail_extra">       I am fine if that is what we want.</div><div class="gmail_extra"><br></div><div class="gmail_extra">  e) More broadly, the use of RDict is unrecognizable from the original design that Barry and I did 14 years ago. I think we</div><div class="gmail_extra">      can just strip this out and replace it with something of equivalent functionality which is simpler and smaller.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt</div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>