Unexpected behavior for `sector` keyword argument in e.g. `exact_diagonalization`

[benjamints]

I am trying to implement a model with a product group structure, and I have run into a problem with exact_diagonalization() returning ArgumentError: invalid sector for valid sectors. In particular, if I convert the FiniteMPOHamiltonian into a TensorMap, then I get all sector as expected. See below code:

using MPSKit, TensorKit
import LinearAlgebra.eigvals

V = Rep[U₁×SU₂]((0, 0) => 1, (1, 1 / 2) => 1)
O = TensorMap(randn, Float64, V ⊗ V ← V ⊗ V)
O = O + O'

N = 4
H = FiniteMPOHamiltonian(fill(V, N), (i, i + 1) => O for i = 1:N-1)

h = convert(TensorMap, H)

# Choose a sector
sectors = collect(blocksectors(h))
sec = sectors[4]

# Works
vals1 = eigvals(block(h, sec))
println(vals1)

# Fails
vals2, _ = exact_diagonalization(H; sector=sec)
println(vals2)

[leburgel]

I think there's some confusion as to what the sector keyword argument in exact_diagonalization means exactly, which is fair since it seems it's not really explained in the docstring. It seems what you're trying to do in the example is to pick out a single block of the Hamiltonian labeled by sec, and then find the regular ground state of that part of the Hamiltonian. That's not what the sector keyword argument for exact_diagonalization means. When you pass a sector to exact_diagonalization, it computes a charged ground state of the full Hamiltonian, meaning the lowest energy eigenvector of the total Hamiltonian in the subspace of charged states with a total charge given by sector. In that sense, the sector keyword argument is similar to what you would pass to excitations to find the excitations within a certain charge sector.

Specifically, when you pass a sector to exact_diagonalization it finds the ground state as a maximum-rank MPS (equivalent to a dense eigenvector) with a non-trivial left virtual space of the leftmost MPS tensor given by ℂ[typeof(sector)](sector => 1). This gives you a finite MPS with a total charge given by sector, exactly like you would do manually by passing a left space to the FiniteMPS constructor. This also means that not all sectors are valid, in the sense that some sectors don't give any valid fusion channels at some sites of the MPS, giving an effectively all-0 state. That's the condition being checked that leads to the error you quote above. A valid sector should be in the dual of the fusion product of all physical charges, meaning it should occur in the dual of the fusion of all physical spaces.

So in summary, exact_diagononalization actually can't be used to do what you're demonstrating for the dense TensorMap Hamiltonian, it can only be used to compute (potentially charged) ground states of the full Hamiltonian.

As an aside then, the reason you're getting an invalid sector error is that the blocksectors of the dense TensorMap Hamiltonian are the sectors that occur in the fusion of all physical spaces, while a valid sector for exact_diagonalization should occur in the dual of this space. This means that your sec just has the opposite sign for its U(1) charge component compared to a valid sector for exact diagonalization.

EDIT: It seems I was a bit too quick in saying that what you were doing with the dense TensorMap is not what exact_diagonalization does. Of course, when imposing a total charge on an eigenvector, the only part of the Hamiltonian that can be multiplied with this state is exactly the part corresponding to the block labeled by the dual of this total charge. I didn't realize this at first, my bad. So you can ignore most of what I said before, the only issue is that you're missing a dual when passing sector=sec to exact_diagonalization, for the reason explained in the paragraph above.

[benjamints]

Ok, I see! I did not actually look carefully at the implementation, so I did not realize that you have to explicitly have to pass the dual rep. It works great now, thanks!

[leburgel]

Going to keep this open just as a reminder that this is indeed quite unintuitive behavior, as most people would agree that what you tried makes more sense than the convention that was chosen.

This will either be closed by #261, or by a follow-up if we decide to systematically change the convention so you don't need the dual anymore.