[NDTensors] [BUG] `eigen` for `BlockSparse` incorrectly assumes sorted eigenvalues

[tipfom]

Description of bug

The eigen routine for BlockSparse tensors incorrectly assumes that the eigenvalues produced by the underlying LAPACK routine are sorted when computing the blockdims here.
This causes unexpected behaviour when truncating non-hermitian ITensor object.

Minimal code demonstrating the bug or unexpected behavior

The following code calls eigen for an ITensor in which after truncation all of the blocks vanish unexpectedly. I've attached the rho.hdf5 file as a rho.zip.

using ITensors, HDF5

f = h5open("rho.hdf5", "r")
M = read(f, "T", ITensor)
close(f)

Linds = (inds(M)[1], inds(M)[2],)
Rinds = (inds(M)[3], inds(M)[4],)
D, U, spec = eigen(M, Linds, Rinds; ishermitian=false, maxdim=5)
@show eigs(spec)
@show inds(D)

Expected output or behavior

I expect the truncation to truncate the smallest eigenvalues or at least return a valid ITensor object with dimension greater than one.

Actual output or behavior

The truncated matrix has no dimensions remaining.

Output of minimal runnable code

eigs(spec) = [0.9780428011067251, 0.026077869361376085, 4.5769159462637974e-5, 1.1487303527514367e-6, 5.205053901626352e-7]
inds(D) = ((dim=0|id=990|"Link,eigen")' <Out>
, (dim=0|id=990|"Link,eigen") <In>
)

Version information

• Output from versioninfo():

julia> versioninfo()
Julia Version 1.11.5
Commit 760b2e5b73 (2025-04-14 06:53 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Windows (x86_64-w64-mingw32)
  CPU: 16 × AMD Ryzen 7 5800H with Radeon Graphics
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, znver3)
Threads: 1 default, 0 interactive, 1 GC (on 16 virtual cores)

• Output from using Pkg; Pkg.status("ITensors"):

julia> using Pkg; Pkg.status("ITensors")
  [9136182c] ITensors v0.9.5

Current fix

On my local instance I fixed the bug by replacing parts of the eigen routine in NDTensors.jl with

p = sortperm(DM; by=abs, rev = true)
DM = DM[p]
VM = VM[:,p]

[mtfishman]

We haven't had a use case for truncated non-Hermitian eigendecompositions so didn't think about that case much... Probably for now that should check if the spectrum is sorted and error if it isn't.