Time evolution for next-nearest neighbor Hamiltonian

[Yue-Zhengyuan]

I plan to start adding the ability to handle Hamiltonians with next-nearest neighbor (NNN) terms (e.g. the J1-J2 model) in the iPEPS time evolution algorithms. There are a number of choices:

1. Simple update: PhysRevB.103.235155 (Fig. 8; I think it's also called the "3-site cluster update" by Corboz in PhysRevB.100.195141 and PhysRevB.108.205154)
2. Full update: PhysRevB.97.174408

This two methods constructs an environment around the 3 sites (using the bond weights / CTMRGEnv) involved in the update to define the cost function. There is another class of "loop update" methods, which treats the 2 x 2 sites around the NNN bond as a PBC-MPS (there will be 3 "physical axes" at each site):

3. PhysRevB.94.075143 This method uses QR/LQ throughout the loop to obtain R, L matrices on the bond to be truncated, and construct projectors on the bond to truncate.
4. PhysRevB.102.075147. This method uses FET to iteratively optimize the tensor at each site on the 2 x 2 loop.

I plan to add the "loop update" methods first. Except the SU method 1, the NNN term is expressed as a 3-site MPO. The loop update can also involve a 4-site MPO in the 2 x 2 loop. But in our current way to store the Hamiltonian as a LocalOperator, each term is a whole gate. Should we add the ability for LocalOperator to store a multi-site term as an MPO, or just do a manual conversion specifically for the time evolution methods?

In addition, could you please also inform me if there are existing methods from MPSKit that can be used to optimize a PBC-MPS?

[lkdvos]

Hi Yue,

For the LocalOperator, I'm definitely open to having a version that stores an MPO instead of the full gates. I am wondering however if we don't want to just have the option to have both: we could simply also add LocalFactorizedOperator, (maybe pick a better name though...) and we can then still decide to remove/replcace the previous LocalOperator at some point if this turns out to be better. This has the added benefit that we can easily test the two against eachother for correctness as well.

To achieve that, I guess the hardest part is to write a similar routine for determining the contraction for arbitrary lattice indices. I can try and have a look at this, but it is definitely also possible to just special case only the versions you currently need and postpone implementing the rest.

For periodic MPS, there is not too much support in MPSKit unfortunately. This is mostly because these algorithms tend to work very differently (since there is no more canonical form), and since no-one has yet needed this there hasn't been too much effort adding this. There are also just way less algorithms available for this.
Of course, the "naive" way of mapping the periodic MPS to a FiniteMPS with squared bond dimension does work, and from what I know of the literature it is not obvious that we can do a lot better here.
The main reason being that methods like PhysRevB.81.081103 work by approximating the transfer matrix of a long subchain, but in our cases we don't have long chains at all.

[leburgel]

+1 for adding additional support for MPO-factorized operators on top of what we have now, and even adding support for actual product operators where instead of an MPO we can represent these as a tuple of rank-2 tensor maps. There's quite a few cases where this happens, and for interactions that act on more than 2 sites this will make a significant difference.

[Yue-Zhengyuan]

For my use cases, I only need MPOs up to length 3 during the time evolution. For measuring of expectation values, I can go back to the 2-site next-nearest neighbor gates and use the old routine, so I have no urgent need to have a general expectation_value for "LocalFactorizedOperator".

[Yue-Zhengyuan]

BTW, does MPSKit have finite MPS algorithms? That can also be helpful in construction of a "local" bond environment for NTU, as I wanted to do here.

[lkdvos]

Yes, for finite MPS there's an entire range of algorithms available