OpenBLAS: scipy test failures on x86_64 with openblas 0.3.6
Since the introduction of openblas 0.3.6 to Fedora rawhide, we’re seeing test failures on scipy builds on x86_64. See https://apps.fedoraproject.org/koschei/package/scipy and in particular: https://kojipkgs.fedoraproject.org/work/tasks/3609/34623609/build.log
Example:
______________________________ TestLSQ.test_lstsq ______________________________
self = <scipy.interpolate.tests.test_bsplines.TestLSQ object at 0x7ff594251cf8>
def test_lstsq(self):
# check LSQ construction vs a full matrix version
x, y, t, k = self.x, self.y, self.t, self.k
c0, AY = make_lsq_full_matrix(x, y, t, k)
> b = make_lsq_spline(x, y, t, k)
scipy/interpolate/tests/test_bsplines.py:1182:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
scipy/interpolate/_bsplines.py:1017: in make_lsq_spline
check_finite=check_finite)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
ab = array([[1.00189868e+00, 7.52101832e-01, 5.38951295e-01, 6.89409012e-01,
6.23893499e-01, 7.79037069e-01, 6.1263...e-04, 5.93585425e-04,
2.05099058e-03, 2.58394962e-03, 0.00000000e+00, 0.00000000e+00,
0.00000000e+00]])
overwrite_ab = True, lower = True, check_finite = True
def cholesky_banded(ab, overwrite_ab=False, lower=False, check_finite=True):
"""
Cholesky decompose a banded Hermitian positive-definite matrix
The matrix a is stored in ab either in lower diagonal or upper
diagonal ordered form::
ab[u + i - j, j] == a[i,j] (if upper form; i <= j)
ab[ i - j, j] == a[i,j] (if lower form; i >= j)
Example of ab (shape of a is (6,6), u=2)::
upper form:
* * a02 a13 a24 a35
* a01 a12 a23 a34 a45
a00 a11 a22 a33 a44 a55
lower form:
a00 a11 a22 a33 a44 a55
a10 a21 a32 a43 a54 *
a20 a31 a42 a53 * *
Parameters
----------
ab : (u + 1, M) array_like
Banded matrix
overwrite_ab : bool, optional
Discard data in ab (may enhance performance)
lower : bool, optional
Is the matrix in the lower form. (Default is upper form)
check_finite : bool, optional
Whether to check that the input matrix contains only finite numbers.
Disabling may give a performance gain, but may result in problems
(crashes, non-termination) if the inputs do contain infinities or NaNs.
Returns
-------
c : (u + 1, M) ndarray
Cholesky factorization of a, in the same banded format as ab
See also
--------
cho_solve_banded : Solve a linear set equations, given the Cholesky factorization
of a banded hermitian.
Examples
--------
>>> from scipy.linalg import cholesky_banded
>>> from numpy import allclose, zeros, diag
>>> Ab = np.array([[0, 0, 1j, 2, 3j], [0, -1, -2, 3, 4], [9, 8, 7, 6, 9]])
>>> A = np.diag(Ab[0,2:], k=2) + np.diag(Ab[1,1:], k=1)
>>> A = A + A.conj().T + np.diag(Ab[2, :])
>>> c = cholesky_banded(Ab)
>>> C = np.diag(c[0, 2:], k=2) + np.diag(c[1, 1:], k=1) + np.diag(c[2, :])
>>> np.allclose(C.conj().T @ C - A, np.zeros((5, 5)))
True
"""
if check_finite:
ab = asarray_chkfinite(ab)
else:
ab = asarray(ab)
pbtrf, = get_lapack_funcs(('pbtrf',), (ab,))
> c, info = pbtrf(ab, lower=lower, overwrite_ab=overwrite_ab)
E SystemError: <fortran object> returned NULL without setting an error
scipy/linalg/decomp_cholesky.py:280: SystemError
Perhaps affected some other packages as well: https://apps.fedoraproject.org/koschei/affected-by/openblas-devel?epoch1=0&version1=0.3.5&release1=5.fc31&epoch2=0&version2=0.3.6&release2=1.fc31&collection=f31
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 58 (22 by maintainers)
FYI, there are no developers working on this project as a full-time job, this project is maintained by a handful of users/volunteers/passersby. Mostly people just fix whatever affects or annoys them, if they have the time and competence.
No problems with a gcc 9.1.0 build either (as far as the build tests and BLAS-Tester are concerned at least, I do not plan to redo the whole scipy thing unless there is additional evidence of an actual problem in OpenBLAS) (One temporary distraction was caused by my first 0.3.6 build somehow still picking the older gfortran, leading to a mixed gcc7.3/9.1 build that linked to libgfortran4 instead of libgfortran5 and promptly bombed out on the first lapack test. I wonder if a segfault in a library call would lead to this “SystemError - returned NULL” effect in python ?)