You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Within a single python process there may be multiple compiled extensions that link to BLAS/LAPACK. When the first package is imported (e.g. numpy), the lapack library used by numpy will be dlopen'ed by the linker. Later, when another package using lapack is imported (e.g. scipy, so3g, toast, etc), if the lapack library has the same name, the linker will use the previously loaded lapack.
This is an issue across the scientific python stack, and has been solved by the community in the following way:
Within the conda ecosystem, package variants can be pinned to a particular blas implementation. This way scipy (and toast) use the same blas as numpy.
Within a single python process there may be multiple compiled extensions that link to BLAS/LAPACK. When the first package is imported (e.g. numpy), the lapack library used by numpy will be dlopen'ed by the linker. Later, when another package using lapack is imported (e.g. scipy, so3g, toast, etc), if the lapack library has the same name, the linker will use the previously loaded lapack.
This is an issue across the scientific python stack, and has been solved by the community in the following way:
We should update the so3g wheels to use this same technique. As a bonus, it will save subtantial CI build time avoiding compilation of OpenBLAS.
At some point in the future we could also consider making conda-forge packages of so3g / sotodlib, but that is a separate exercise.
The text was updated successfully, but these errors were encountered: