Suggestion: not allow numpy and/or scipy imported before cytnx

[chiamin]

I realized that importing numpy and/or scipy before cytnx can lead to incorrect results without any clue. This is degerous and it should not be only a warning. I strongly suggest making it an Error to forbid importing numpy/scipy before cytnx.

In the long term, ideally, this dependency should be fixed.

I attached an example code to demonstrate different behaviors with/without importing numpy.

qn_complex_contract_norm_bug.py

[IvanaGyro]

qn_complex_contract_norm_bug.py

import numpy as np
import cytnx

sym = cytnx.Symmetry.U1()

# Build a complex QN UniTensor directly
phi = cytnx.UniTensor(
    [cytnx.Bond(cytnx.BD_IN,  [[0], [1]], [1, 1], [sym]),
     cytnx.Bond(cytnx.BD_OUT, [[0], [1]], [1, 1], [sym])],
    rowrank=1, dtype=cytnx.Type.ComplexDouble,
)
phi.set_labels(["a", "b"])

# phi = [1 0
#        0 i]
phi[0,0] = 1.0
phi[1,1] = 1.j
print(phi)

# A = <phi|phi>, should be a scalar 2
A = cytnx.Contract(phi.Dagger(), phi)
# If import numpy before cytnx, A=0 (wrong);
# otherwise, A=2 (correct)
print(A)

[IvanaGyro]

I guess this is the same issue as #595 (comment)

[IvanaGyro]

Copy from: #595 (comment)

I suggest we detect the validity of BLAS at runtime like what numpy does. We may add a testcase like this

A = np.array([[1., -3.j], [3.j, 2.]], dtype=np.complex128)
print(np.linalg.matrix_rank(A, hermitian=True))

but a Cytnx version.

[chiamin]

I realized that this is a more complicated issue than I thought...

I failed to install ILP64 numpy in conda, so I am running with LP64 numpy. Consider two tests: 1. Cytnx.Contract for complex QN tensors, and 2. np.linalg.eigh.

• If import cytnx first, and then import numpy:
  Cytnx.Contract: Good
  np.linalg.eigh: Bad
• If import numpy first, and then cytnx:
  Cytnx.Contract: Bad
  np.linalg.eigh: Good

So either case will have an error. I attached an example code.

mkl_ilp64_conflict.py

I would suggest making an LP64 version of Cytnx for conda install and letting users choose.

[ianmccul]

64 bit integers in blas is a huge problem because the BLAS vendors basically screwed it up hugely. If you compare other OS interfaces that had a 32 -> 64 bit transition they handled it much better. I agree, the only real solution, given the state of BLAS libraries that exist today, is to detect at runtime whether the blas library is using 32 or 64-bit integers, and then either compensate or give an error and exit immediately. What should have happened is a 64-bit version of BLAS that uses different names, dgemm_32 for 32-bit and dgemm_64 for 64-bit etc. Unless you can control at compile time exactly which BLAS library you get (which you cannot, if it is a shared object loaded as libblas.so) I think the only option is detect at runtime and be prepared to either hard-error or able to cope with either 32 or 64 bit. Its a huge mess.

[chiamin]

For now, a useful and relatively easy option would be an LP64 (32-bit) version of cytnx in conda. It won't hurt the current version. I would appreciate it if someone could build it.

[IvanaGyro]

#601 seems have set default blas to LP64.

[yingjerkao]

Generated by Claude @claude

This is exactly the BLAS/LAPACK symbol collision issue caused by import order affecting which shared library's symbols win at dynamic link resolution.

Agreed that silently producing wrong results is worse than a hard error. In the short term, raising an ImportError if numpy/scipy are detected in sys.modules before cytnx is imported is a reasonable safeguard.

The proper long-term fix is to ensure cytnx's __init__.py forces NumPy's BLAS to load globally before the C++ extension is imported, so both share the same symbols:

# cytnx/__init__.py
import ctypes
import numpy as _np

# Force NumPy's BLAS/LAPACK into the global symbol namespace
# before loading our pybind11 extension, preventing symbol collision
for _lib in _np.__config__.get_info('blas_opt').get('libraries', []):
    try:
        ctypes.CDLL(f"lib{_lib}.so", mode=ctypes.RTLD_GLOBAL)
    except OSError:
        pass

from ._cytnx import *  # load C++ extension after BLAS is globally visible

This way the import order no longer matters — cytnx itself ensures the correct initialization sequence regardless of what the user has already imported. This is the same pattern used by JAX and other scientific Python packages that wrap BLAS-linked native extensions.

---

By me,

I don't see an easy fix for this. We got weird error when we used MKL runtime library previously, so I fixed it to LP64. I will tackle this again later.

[chiamin]

#601 seems have set default blas to LP64.

cytnx in conda installation uses ILP64 for cytnx and LP64 for numpy (BLAS). I use the following script to check them (written by Claude) check_blas_int_size.py. One can use mkl_ilp64_conflict.py to reproduce the error or the incorrect behavior.

I can install LP64 cytnx from the source code, but conda is probably more convenient for students, so a conda LP64 cytnx is still useful.

[chiamin]

Generated by Claude @claude

This is exactly the BLAS/LAPACK symbol collision issue caused by import order affecting which shared library's symbols win at dynamic link resolution.

Agreed that silently producing wrong results is worse than a hard error. In the short term, raising an ImportError if numpy/scipy are detected in sys.modules before cytnx is imported is a reasonable safeguard.

The proper long-term fix is to ensure cytnx's __init__.py forces NumPy's BLAS to load globally before the C++ extension is imported, so both share the same symbols:

cytnx/init.py

import ctypes
import numpy as _np

Force NumPy's BLAS/LAPACK into the global symbol namespace

before loading our pybind11 extension, preventing symbol collision

for _lib in _np.config.get_info('blas_opt').get('libraries', []):
try:
ctypes.CDLL(f"lib{_lib}.so", mode=ctypes.RTLD_GLOBAL)
except OSError:
pass

from ._cytnx import * # load C++ extension after BLAS is globally visible
This way the import order no longer matters — cytnx itself ensures the correct initialization sequence regardless of what the user has already imported. This is the same pattern used by JAX and other scientific Python packages that wrap BLAS-linked native extensions.

By me,

I don't see an easy fix for this. We got weird error when we used MKL runtime library previously, so I fixed it to LP64. I will tackle this again later.

I am not sure that the issue can be resolved by the import ordering. One would get either cytnx.Contract error or np.linalg (BLAS) error in each one of the cases. (See mkl_ilp64_conflict.py) I think it is safer to enforce both cytnx and numpy (BLAS) to use the consistent lp64 or ilp64.

[IvanaGyro]

#601 seems have set default blas to LP64.

cytnx in conda installation uses ILP64 for cytnx and LP64 for numpy (BLAS). I use the following script to check them (written by Claude) check_blas_int_size.py. One can use mkl_ilp64_conflict.py to reproduce the error or the incorrect behavior.

I can install LP64 cytnx from the source code, but conda is probably more convenient for students, so a conda LP64 cytnx is still useful.

I guess because we haven't released a new version since then.