Multiplication of `InfiniteMPOHamiltonian` with `InfiniteMPS`

[borisdevos]

I tried to multiply an InfiniteMPOHamiltonian with a InfiniteMPS, as I recalled this was possible in MPSKit@v0.11.x (this being the relevant code for v0.11.6). However, it seems this isn't supported in v0.12. What does exist, is the multiplication of a FiniteMPOHamiltonian with a FiniteMPS (relevant code here).

A MWE:

julia> using TensorKit, MPSKit, MPSKitModels

julia> sp = SU2Space(1=>1,1//2=>1)
julia> h = TensorMap(rand, ComplexF64, sp^2 ← sp^2)
julia> H = @mpoham sum(h{i,j} for (i,j) in nearest_neighbours(InfiniteChain(1)))
julia> init = InfiniteMPS([sp],[sp])

julia> H*init
ERROR: MethodError: no method matching *(::InfiniteMPOHamiltonian{BlockTensorKit.SparseBlockTensorMap{…}}, ::InfiniteMPS{TensorMap{…}, TensorMap{…}})

julia> Hfin = @mpoham sum(h{i,j} for (i,j) in nearest_neighbours(FiniteChain(4)))
julia> init_fin = FiniteMPS(4, sp, sp)
julia> Hfin * init_fin # no error

Converting first to InfiniteMPO also errors:

julia> InfiniteMPO(H)*init
ERROR: MethodError: no method matching fuser(::Type{…}, ::GradedSpace{…}, ::BlockTensorKit.SumSpace{…})

What does work is to first convert the InfiniteMPOHamiltonian to a MPSKit.DenseMPO, and then perform the multiplication. I would think something like

Base.*(H::InfiniteMPOHamiltonian, mps::InfiniteMPS) = convert(DenseMPO, H) * mps

similar to v0.11.x should suffice, unless this isn't the wanted behavior of this multiplication.

Extra info:
Julia Version 1.10.1
MPSKit v0.12.6
MPSKitModels v0.4.1
TensorKit v0.14.5

[lkdvos]

I think the main problem is that this is not really so well defined, since the Hamiltonian is an infinitesimal operator, you really should first exponentiate it before you can apply it to a state and get out a state. I'm not sure why we supported this previously, but there are definitely some issues with the extensive properties if you simply apply the InfiniteMPOHamiltonian as is.
In the finite case this is less of a problem, although it is probably still not something you really want to rely on.

I'm not entirely sure what it is that you would like to use this for, but in general you probably want something like: make_time_mpo(H, dt, alg) * state, which is extensive again?

[borisdevos]

I'm not sure if I follow your argument. You are allowed to evaluate something like $$\hat{H} \ket{\psi} = E \ket{\psi}$$, even if your Hamiltonian is an infinite-dimensional matrix and your wave-function an infinite-dimensional vector.

I do understand your extensivity argument. I guess I'm just confused as to how an InfiniteMPOHamiltonian is "local".

[leburgel]

I think your suggestion of converting to a DenseMPO and then doing the multiplication works fine in practice. So you can already do this. I think Lukas' point is that there's not really an obvious well-defined application for this, so he doesn't think it's a good idea to add support for this in the package itself. Both your question and Lukas' concerns are a bit vague however, so it would be good to clarify what you both mean.

For starters, what exactly is it that you want to do @borisdevos? I mean not just applying the Hamiltonian, but also what you intend to do with the result.

A simple argument against adding support for what you want is already that while $$\hat{H} \ket{\psi} = E \ket{\psi}$$ is perfectly well-defined on paper, in practice $$E$$ is just infinite (which is definitely an 'extensivity issue'). Already just from a practical point of view, this means the resulting MPS is not normalized, and this might for example mess up quite a lot of routines which assume proper normalization.

[lkdvos]

Let me try and make this slightly less vague and more practical:

One of the more subtle differences between the operator and Hamiltonian cases is the boundary conditions: in order for the Hamiltonian to generate the correct sum you require $v_L = (1 0 0)$ and $v_R = (0 0 1)^T$.
In practice, this happens behind the screens and the algorithms insert this correctly through the environments.

While you can convert to a dense mpo and simply apply, the resulting mps will be non-injective because of the structure of the Hamiltonian, this is easy to check:

H = transverse_field_ising()
psi = InfiniteMPS(2, 12)
Hpsi = MPSKit.DenseMPO(H) * psi

julia> transfer_spectrum(Hpsi)
20-element Vector{ComplexF64}:
    0.999999999999998 - 4.810537276682403e-16im
   0.9999999997226539 - 1.7249656564244376e-16im
   0.9999999997226511 - 1.0427425517839817e-16im
    0.999999999445303 + 7.75611976174765e-16im
 -0.13294988321675674 - 0.0004885220655259795im
 -0.13294988315447176 + 0.0004885219038751041im
                      ⋮
  0.09367270408267775 - 0.02439320457551515im
  0.09367270320102117 + 0.024393200317853282im
  0.09367270319937189 - 0.024393200316789012im
  0.09367270315823764 + 0.02439319572800022im
  0.09367269926728576 + 0.024393202671455266im
  0.09367269908108444 - 0.024393199011923154im

I might be completely wrong about this, but there also seems to be some differential geometry inconsistencies here.
The Hamiltonian is really just an infinitesimal generator of time evolution, characterised by $U(t) = exp(-iHt)$.
Given Hermitian Hamiltonians, this is unitary time evolution and we map states to states (preserving inner product etc).

Note here that while the evolution operator belongs to the group, the Hamiltonian belongs to the algebra, which is the tangent space to the identity element of the group.
As a result, applying $H$ to a state gives a tangent vector, it tells you how the state would change infinitesimally under the flow of the evolution.
However, the tangent vector doesn't have to be a state itself, it is not a point on the manifold.
This is already clear in practice: it doesn't have a unit norm.

Long story short: $H | \psi >$ is the velocity vector of the curve $exp(-iHt) | \psi >$ at $t=0$, which is not a state. Therefore naively multiplying might be a bit misleading, and since our InfiniteMPS always has to have norm 1 I think it is better to not enable * to do this by default, and require a bit more work.

[lkdvos]

I'll close this issue as not planned for now, let me know if we need to expand on this in the docs or there is a better solution for this.

[borisdevos]

Long story short: I have no use for this to "actually work". I had this particular action in the finite case be useful at some point, and I knew it existed in earlier versions for the infinite case, so the issue was more to point out that this was missing. I have now learnt that this was intentional. I'm on board with closing this (for now). Thanks for your kind explanations :)