I think it’s worth sharing this since it took me quiet some time and installing petsc from source is a bit of a challenge. Maybe we can link this post in the original thread.
I had exactly the same issue as described in this (unresolved) post… I also ran make all test in order to successfully test my petsc installation, but cmake refused to pick up the petsc installation. In the end, I managed it by using the following commands (after downloading the sources):
I think the main point here is the definition of the compiler. I used gcc 10.2 and OpenMPI 4.0.4 and not the mpi wrapper. I think preCICE does the same thing in the end.
However, in my first installation, I also had a non-default installation prefix and I don’t recommend to use it, i.e., install petsc directly in the build directory.
Why are you using ./config/configure.py instead of ./configure for the configuration? Could this have some side effects?
I never had problems with installing PETSc in user-defined prefix. Normally I build on some temporary filesystem and install in my home directory. I have used the newer versions of preCICE with self-compiled PETSc without any problem. I would also advice against installing PETSc in its build directory. I had weird side-effects due to that some times. However, one has to set the environment variables carefully.
Which version of preCICE are you using? The PETSc detection has been recently reworked. I had some troubles with the detections of PETSc from preCICE, but that was normally the case when using Spack. It was very odd in the sense that it would pick up the PETSc and technically find the library, but the CMake script would still fail.
If you have some logfiles it would be interesting to see them. Maybe there is still something hidden in there that could be useful.
In the end I was not sure if it really resolved the problem. Since PETSc has its own pkgconfig, it might of course lead to side effects, when preCICE locates an ‘uninstalled’ pkgconfig file containing some default prefix installation path. However, for me it worked much better in the end. I think the environment variables are the key aspect here. AFAIK the mpi wrapper also set some environment variables.
This was more or less preCICE v2.2 ( two week before release (?)). The failing CMake test was exactly what happend with my first installation, but also with the available modules on the cluster (which might be similar to spack in the end). The log files have unfortunately been overwritten when I compiled the my most recent PETSc version (as described above).
Just for reference, I set the following environment variable for PETSc:
PETSC_DIR: Root directory of my PETSc installation, e.g., /home/ajaust/software/petsc/debug/petsc-3.13.3
PETSC_ARCH: This variable is set according to what the installation script of PETSc gives me, e.g., arch-linux-c-debug. The arch is not in the path I install PETSc in. This is/was common in the past, but it does not seem to be mandatory anymore.
LD_LIBRARY_PATH, LIBRARY_PATH and PYTHONPATH: All set to ${PETSC_DIR}/lib.
CPATH: Set to ${PETSC_DIR}/include
CMAKE_PREFIX_PATH: Set to ${PETSC_DIR} as otherwise PETSc was not found (anymore) by one of the intermediate preCICE installation scripts.
As outlined above, the described solution was more a continuation of the original post. So, a potential solution might be given by myself or by the response of @ajaust.
The PETSc discovery from preCICE 2.2.0 onwards relies on the pkg-config instead of the detection tests executed before (which were prone to fail).
Using pkg-config has some limitations:
PETSc can only be used from the build directory if it wasn’t configured with --prefix=.
PETSc can only be used from the installation directory if it was configured with --prefix=.
If using from the build directory, defining PETSC_ARCH or cmake -DPETSc_ARCH= is required.
preCICE uses FindMPI to detect the MPI installation. This won’t find self-installed MPI implementations of PETSc.