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

[Barry Smith]

   I've never found a likable version of BLAS/LAPACK, just versions I could live with :-)



> On Oct 24, 2022, at 12:31 PM, Satish Balay <balay at mcs.anl.gov> wrote:
> 
> 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
>