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

[Satish Balay]

Hm - I see numpy on older OS - but not on M1. So Apple no longer bundles it?

And pip creates grief on NFS :(

Satish

------

balay at ypro ~ % sw_vers 
ProductName:	Mac OS X
ProductVersion:	10.15.7
BuildVersion:	19H2026
balay at ypro ~ % python3 -c "import numpy; print(numpy.__file__)"
/Users/balay/Library/Python/3.8/lib/python/site-packages/numpy/__init__.py
balay at ypro ~ % 


compute-macos-240-02:~ balay$ sw_vers 
ProductName:	macOS
ProductVersion:	12.3.1
BuildVersion:	21E258
compute-macos-240-02:~ balay$ python3 -c "import numpy; print(numpy.__file__)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'numpy'
compute-macos-240-02:~ balay$ 




On Mon, 24 Oct 2022, Zhang, Hong via petsc-dev wrote:

> The chances of these problems are very slim because almost nobody builds Numpy from source. I usually install it with pip. Pip-installed Numpy on Mac uses Openblas, which is shipped together with the numpy wheels. The official API to check which BLAS is used by Numpy is numpy.show_config(). However, it gives me false info on my laptop — the openblas libs do not really exist in /usr.local/lib.
> 
> openblas64__info:
>     libraries = ['openblas64_', 'openblas64_']
>     library_dirs = ['/usr/local/lib']
>     language = c
>     define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None)]
>     runtime_library_dirs = ['/usr/local/lib']
> blas_ilp64_opt_info:
>     libraries = ['openblas64_', 'openblas64_']
>     library_dirs = ['/usr/local/lib']
>     language = c
>     define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None)]
>     runtime_library_dirs = ['/usr/local/lib']
> openblas64__lapack_info:
>     libraries = ['openblas64_', 'openblas64_']
>     library_dirs = ['/usr/local/lib']
>     language = c
>     define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None), ('HAVE_LAPACKE', None)]
>     runtime_library_dirs = ['/usr/local/lib']
> lapack_ilp64_opt_info:
>     libraries = ['openblas64_', 'openblas64_']
>     library_dirs = ['/usr/local/lib']
>     language = c
>     define_macros = [('HAVE_CBLAS', None), ('BLAS_SYMBOL_SUFFIX', '64_'), ('HAVE_BLAS_ILP64', None), ('HAVE_LAPACKE', None)]
>     runtime_library_dirs = ['/usr/local/lib']
> Supported SIMD extensions in this NumPy install:
>     baseline = SSE,SSE2,SSE3
>     found = SSSE3,SSE41,POPCNT,SSE42,AVX,F16C,FMA3,AVX2
>     not found = AVX512F,AVX512CD,AVX512_KNL,AVX512_SKX,AVX512_CLX,AVX512_CNL,AVX512_ICL
> 
> I think Numpy is actually using the following openblas lib:
> /usr/local/lib/python3.10/site-packages/numpy//.dylibs/libopenblas64_.0.dylib
> 
> I feel that it would be a big hassle if we want to determine the BLAS that Numpy is using, considering the different ways and platforms Numpy may be installed.
> 
> Hong (Mr.)
> 
> On Oct 21, 2022, at 4:20 PM, Barry Smith <bsmith at petsc.dev<mailto:bsmith at petsc.dev>> 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
> 
>