Expose more optional feature booleans, remove Timer from top level dolfinx

[jhale]

This PR removes Timer functionality from the top-level dolfinx module and exposes all of the C++ compile definitions through to Python, including a new dolfinx.has_petsc4py boolean.

[schnellerhase]

We previously missed the HAS_PETSC4PY flag in these exports as well, might be a good place to add that one as well? Also, when this is exported some of the demos (the ones using non linear solvers I think) should probably check for both has_petsc and has_petsc4py, instead of only has_petsc.

[jhale]

These flags are related to the optional features of the C++ library only. Python can perform runtime introspection.

if importlib.util.find_spec("petsc4py") is not None:
    import dolfinx

    if not dolfinx.common.has_petsc:
        print("This demo requires DOLFINx to be compiled with PETSc enabled.")
        exit(0)

    from petsc4py import PETSc

    if PETSc.IntType == np.int64 and MPI.COMM_WORLD.size > 1:
        print("This solver fails with PETSc and 64-bit integers becaude of memory errors in MUMPS.")
        # Note: when PETSc.IntType == np.int32, superlu_dist is used rather
        # than MUMPS and does not trigger memory failures.
        exit(0)
else:
    print("This demo requires petsc4py.")
    exit(0)

The logic here is: OK, I found petsc4py, but did you build DOLFINx with PETSc? If not, then DOLFINx cannot build PETSc data structures anyway, and the demo cannot be run.

[schnellerhase]

Yes, but if I'm not overseeing something here, the cpp may be configured with petsc but the python module build without petsc4py being available, see

dolfinx/python/dolfinx/wrappers/dolfinx.cpp

Line 77 in 8e4122b

#if defined(HAS_PETSC) && defined(HAS_PETSC4PY)

. In which case the flag common.has_petsc will be true, as set by the cpp build, but no nls submodule will be available. This is also independent of the python import of petsc4py working I guess, could have been made available after the python module install.

[jhale]

Right, thanks for explaining - I see your point. It's probably clearest to expose both and the tests in the demos should check if DOLFINx Python was built with petsc4py support (which in turn requires DOLFINx C++ to be built with PETSc support).

[jhale]

@garth-wells This patch does make the top level namespace cleaner but is an API change. My view is that has_* are not commonly used enough to justify their presence cluttering autocompletion on dolfinx.*. Nevertheless it's not something I feel strongly about. What would you prefer?

[jhale]

In support of keeping has_* in dolfinx is that is consistent with the C++ interface where these are in namespace dolfinx::.

[garth-wells]

I don't particularly like this change. It adds clutter, but I don't see the benefit. Properties like has_foo are 'properties' of dolfinx, so I prefer things as they are.

[jhale]

I will modify this patch so that we have:

• dolfinx.has_foo with the new additional flags.
• Move dolfinx.Timer etc. to dolfinx.common.Timer This makes the Python interface consistent with the C++ interface https://github.com/FEniCS/dolfinx/blob/main/cpp/dolfinx/common/Timer.h#L13