[petsc-dev] [petsc-users] Using PETSC with an openMP program

[Matthew Knepley]

On Fri, Mar 2, 2018 at 12:58 PM, Jed Brown <jed at jedbrown.org> wrote:

> Adrián Amor <aamor at pa.uc3m.es> writes:
>
> > 1. I have compiled PETSC with these options:
> > ./configure --with-cc=mpiicc --with-cxx=mpiicpc --with-fc=mpiifort
> > --with-blas-lapack-dir=/opt/intel/mkl/lib/intel64/ --with-debugging=1
> > --with-scalar-type=complex --with-threadcomm --with-pthreadclasses
> > --with-openmp
> > --with-openmp-include=/opt/intel/compilers_and_libraries_
> 2016.1.150/linux/compiler/lib/intel64_lin
> > --with-openmp-lib=/opt/intel/compilers_and_libraries_2016.
> 1.150/linux/compiler/lib/intel64_lin/libiomp5.a
>
> Matt, --with-threadcomm and --with-pthreadclasses were removed in 2015,
> but people still use these options and think they are doing something
> because configure doesn't even mention unused options.  We've been
> talking about fixing this for at least a decade, and yet here we still
> are.  Things like this get fixed in the C code, so it can't be pure
> laziness.  Python is supposed to be easy, but this part of BuildSystem
> is evidently scary.  I have no idea if fixing this would be a 2-hour job
> or if it would snowball into more than 20.  It's hard to estimate time
> to make cross-cutting changes, but in my experience, BuildSystem is
> especially hard to make estimates about.  I spent an hour or two trying
> to assess this particular issue and came up empty-handed some years ago.
> I've had several other false starts over the years, trying to make minor
> improvements to BuildSystem and finding a web of subtle dependencies.
> The PETSc library tends to have well-documented interfaces with minimal
> side-effects, but BuildSystem has a lot of similarly-named undocumented
> (or inaccurately-documented) interfaces with implications that are hard
> to reason about.  I don't have an immediate solution, but this technical
> debt is costly.  It works, in many ways functionally better than
> alternatives, but it's really hard to work on.
>

I guess my superficial response to this is

  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.
      However, I am interested in fixing problems, since I think it is
still the best available way to do these things.

  b) Broad criticisms are very useful as a way to introduce specific
criticisms that can be worked on. Divorced from that
      grounding, they are much less useful.

  c) I believe that you have a hard time making modifications. I would note
that this code has received a steady stream of
      updates for its entire existence, so it is not impossible, but
perhaps too hard.

  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
       are held. Put in a marker which gets set when the option is
accessed, just as we do in PETSc. The problem is really
       that configure is likely to produce many more false positives, as
people often put in things that might not be accessed.
       I am fine if that is what we want.

  e) More broadly, the use of RDict is unrecognizable from the original
design that Barry and I did 14 years ago. I think we
      can just strip this out and replace it with something of equivalent
functionality which is simpler and smaller.

   Matt

-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180302/1ef886f3/attachment.html>