[petsc-dev] petsc4py, numpy's BLAS and PETSc's BLAS

[Satish Balay]

Yes - this always bothered me... 

But I don't think its always possible to automate it.

The likable version [.so] might not exist - only .so.ver might exist? [and it might use blas but not lapack?]

Note: one way to avoid this issue is to let spack install python,numpy,petsc,petsc4py

Satish

-------
$ locate numpy |grep \.so$ |grep python3.11
/usr/lib64/python3.11/site-packages/numpy/core/_multiarray_tests.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/core/_multiarray_umath.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/core/_operand_flag_tests.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/core/_rational_tests.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/core/_simd.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/core/_struct_ufunc_tests.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/core/_umath_tests.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/fft/_pocketfft_internal.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/linalg/_umath_linalg.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/linalg/lapack_lite.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/_bounded_integers.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/_common.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/_generator.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/_mt19937.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/_pcg64.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/_philox.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/_sfc64.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/bit_generator.cpython-311-x86_64-linux-gnu.so
/usr/lib64/python3.11/site-packages/numpy/random/mtrand.cpython-311-x86_64-linux-gnu.so
$ locate numpy |grep \.so$ |grep python3.11 |xargs ldd |grep = | cut -d = -f 2 | cut -d " " -f 2 | sort | uniq
/lib64/libc.so.6
/lib64/libflexiblas.so.3
/lib64/libgcc_s.so.1
/lib64/libgfortran.so.5
/lib64/libm.so.6
/lib64/libquadmath.so.0


On Fri, 21 Oct 2022, Barry Smith wrote:

> 
>   When PETSc is built with petsc4py this brings along, in some way, the BLAS/LAPACK that numpy is using. Yet PETSc is free to bring in its own BLAS/LAPACK libraries. 
> 
>   To be completely proper should we be having configure (when used with petsc4py) determine the BLAS/LAPACK that numpy is using and only using that for PETSc's BLAS/LAPACK needs?  If not, why is ok to have both sets hanging around? Jose's new https://gitlab.com/petsc/petsc/-/merge_requests/5737 seems to indicate possible problems with having both.
> 
>   Barry