Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InfiniteITensorSum and MPO representations of local Hamiltonians #32

Open
LHerviou opened this issue Jan 24, 2022 · 3 comments
Open

InfiniteITensorSum and MPO representations of local Hamiltonians #32

LHerviou opened this issue Jan 24, 2022 · 3 comments

Comments

@LHerviou
Copy link
Contributor

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.

@mtfishman
Copy link
Member

mtfishman commented Jan 24, 2022

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).

@mtfishman
Copy link
Member

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.

@LHerviou
Copy link
Contributor Author

I think it is indeed the best. The MPO method is quite tricky to implement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants