How to properly use the MPS and MPO methods for arbitrary MPOs?

Question

Hi,

using the MPS and MPO classes and methods, I find some behaviour which is contradictory to what I think should happen. Therefore, I wanted to make sure to use these classes in a valid way (which I meanwhile doubt a lot):

What I want to do: I want to contract a periodic MPS with a periodic MPO a couple of times (both with arbitrary bond dimension, physical as well as virtual, such that the builders such as AutoMPO don't seem adequate to me?).

What I do: So I initialize my site set sites and initialize sets of virtual indices once for the MPS and once for the MPO mpo_inds and mps_inds. I initialize an MPO and MPS object
MPS myMPS (sites)
MPO myMPO (sites)
then for each site site_ I create tensors mps_A and mpo_A that fullfill my index structure defined in mps_inds and mpo_inds. Then I simply set
myMPS.Aref(site_) = mps_A;
myMPO.Aref(site_) = mpo_A;

What I would expect: So now I would expect that using exactApplyMPO should yield the same result (modulo gauge invariance) as initializing a new MPS defined through tensors of the form mps_A * mpo_A (combining the double index to a new index and building an adequate index set for the MPS build this way etc ...)
However, after normalizing each of the states I find that:
overlapC(myMPS_, myOtherMPS) = 0.86 - 0.95
whilst
overlapC(myMPS_, myMPS_)=overlapC(myOtherMPS, myOtherMPS) = 0.99 - 1.0
where myOtherMPS is the manually defined contraction, whilst myMPS_ is the result from exactApply(myMPS, myMPO, myMPS_).

So, to me it seems that 1) obviously the states myMPS_ and myOtherMPS aren't the same whilst 2) they stay surprisingly close (still about 90% +- 5% overlap) all the time (where I do use randomly generated ITensors for the MPO and MPS initialization).

What is it that I am misusing, or how to do this in the correct way?

Best wishes,
Alex

Answer 1

Hi Alex,
So exactApplyMPO, and indeed most functions in ITensor, assume open boundary conditions or in some cases also work with "dangling" indices off the left and right for cases involving unit cells of larger or infinite systems. We have very few facilities for dealing with periodic boundary conditions because the technology (in the broader tensor network literature I mean) for working with periodic MPS and MPOs is quite poor.

This is good feedback though, as for me it's so implicit that we're always using open boundaries that I did not think to mention it in the documentation. So I should go through and mention that in the docs.

May I ask why you need periodic boundary conditions? You may need them, but sometimes I find that people are using them in cases where just using open boundaries and going to larger system sizes would work just as well or usually much better.

Miles

Comments

Hi Miles,

of course you may ask! I use ITensor mainly to code PEPS methods. .

Now I was trying to code variants of the corner transfer matrix method for PEPS on the cylinder (cf. 1705.03222). First I thought about coding a finite uniform MPS code instead of the renormalization scheme as in Appendix B. However, I encountered exactly the lack of technology you were referring to. Then I thought the ITensor build-in exactApplyMPO method should do in principle exactly the job. So I gave it a try to use it kind of as a black box tool.
However, remembering the lack of technology I was not too surprised that it did not work. Still, I wanted to make sure where exactly the problem is hidden :)

---

Yes, I see - that's helpful to know. We only want to include algorithms in ITensor that are pretty reliable and have good scaling. So we've avoided supporting any periodic MPS techniques since I think generally people would be disappointed in their performance or reliability. Also we (Steve White's group) almost never use periodic boundary conditions in our research with the exception of doing 2D-DMRG on cylinders. So I can see why you'd want to do that for PEPS too.