[petsc-dev] Tons of errors with an unusual PETSc configuration

Lisandro Dalcin dalcinl at gmail.com
Thu Apr 18 02:31:38 CDT 2019

On Wed, 17 Apr 2019 at 18:42, Smith, Barry F. <bsmith at mcs.anl.gov> wrote:

>     Moving to PETSc dev for more input
>     Lisandro,
>        I understand the rational for not wanting it on by default for
> random user code but the fact is that is is NEEDED to compile the PETSc
> source (and examples) and so seems wrong that those configurations can only
> be built if the user provides this obscure flag
I agree. My work to fix the issue is incomplete indeed, but the leftover is
rather small. This would probably involve modifying things in BuildSystem,
and I have a tendency to not mess with things I do not understand well.

>       We could have it on by default and have a flag
> PETSC_SKIP_CXX_COMPLEX_FLOAT_WORKAROUND that users put in before they
> include any PETSc includes but I suspect you won't like this?

It does not really matter to me, as long I'm not the one to be blamed by
taking that decision :-) . This change will not affect any of my own codes,
so I do not have any personal agenda here.

      Somehow have the gnu make system pass in the flag
> examples but not other code? How to organize that?

This is something we should definitely do. PETSc source code is our
codebase, we are always in control of fixing things around.

>        Define PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND at the top of every
> PETSc source file that needs it (and examples that need it)? Ugly, but
> doable?
No, please!

>        "Fix" the PETSc source code so the issues it handles don't come up?
> Or reduce them and stick the PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND just in
> the troublesome files?

No way, I already looked into that.

* Too much work to fix a broken the standard std::complex<float> template.
* Too many ugly (PetscReal) casts here and there in the codebase
* And it is not only the problem of fixing the current code, this issue
will continue to popup.

>       Any other way to have it on when needed but off otherwise?
 My final recommendation would be:

1) Put the relevant workaround code in a separate header users can #include
in their own code, let say #include <petsccomplexfloat.h>, we can even put
it under the private/ include folder.
2)  Keep the PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND in "petscmat.h", and
make it #include <petsccomplexfloat.h>.
3) Modify our top level gmakefile to pass
-DPETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND, but only if we are building with
lang=C++, scalar=complex, precision=single. For example, we can make
configure write a
it ONLY in the toplevel gmakefile, NOT in
`$(PETSC_DIR)/lib/petsc/conf/variables`. Also gmakefile.tests?

This way users can use the workaround in two ways, either by #include
<petsccomplexfloat.h> or by defining PETSC_USE_CXX_COMPLEX_FLOAT_WORKAROUND
themselves (either on source before including petsc.h or via makefiles
variables). And we fix the issue when building PETSc in a rather
transparent and non-obtrusive way.

Now, Barry, seat in the Iron Throne and rule! And if someone complain, use
dragon fire... like in the good old days.


Lisandro Dalcin
Research Scientist
Extreme Computing Research Center (ECRC)
King Abdullah University of Science and Technology (KAUST)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20190418/35ac346c/attachment.html>

More information about the petsc-dev mailing list