Open LHerviou opened 2 years ago
I was going to suggest that as an option based on our discussion in #31.
We could always convert an InfiniteITensorSum
into an InfiniteMPOSum
internally, so the code is always just written in terms of InfiniteMPOSum
but users can input either one. We can easily do the conversion with a series of SVDs (EDIT: there is also an MPO(::ITensor)
conversion function in ITensors.jl which is implemented exactly this way). This could have a few advantages, like making it easier to represent fermions and taking advantage of possible compressibility of the local Hamiltonian terms.
However, I don't see why it would be impossible to represent long range interactions with an InfiniteITensorSum
. It only needs to have the sites in the support of the operators, not all the ones in between. If there are operators in between, like if there is a Jordan-Wigner string, that is another matter, but that could be handled in other ways efficiently, like with fermionic swap gates. But fermions would be a good use case for using an InfiniteMPOSum
representation, since it would make it a lot simpler (the Jordan-Wigner string could then be input automatically in the MPO by the OpSum/AutoMPO functionality from ITensors.jl).
In the end, it would be best to directly use just a single MPO, so I think it is up to you. It sounds like you've made good progress on implementing the sum-of-local-terms approach, in which case I would vote for getting that working as generally as you can internally using an InfiniteMPOSum
representation, and then use that as a reference code when making a proper MPO
-based VUMPS implementation.
I think it is indeed the best. The MPO method is quite tricky to implement.
For the case I am interested in (FQHE-like Hamiltonians), the local Hamiltonian can be very long range (approximately 15-20 sites would be good to reach). Writing the full local Hamiltonian is therefore impossible. Instead, it is possible to write a finite MPO representation of the local Hamiltonian. It is not currently possible with the current definition of the InfiniteITensorSum.
Proposition: would a InfiniteMPOSum class interesting to anyone else? Essentially identical to the InfiniteITensorSum, except it has a Cell of MPOs instead of ITensors. It probably only requires one or two days of work to interface all the code. Drawback: quite a lot of code repeat. Another possibility is: an abstract class AbstractInfiniteITensorSum which is inherited by both, and a few definitions of functions (for left environment typically) which would be class dependent.
Of course, this problem could be moot: it might be more efficient to directly go with a full MPO representation of the Hamiltonian.