[ENH] CTMRG arbitrary unit cell

[ogauthe]

Currently, PEPSKit CTMRG assumes each site in the unit cell is different. For a 2x2 unit cell, it imposes a AB//CD pattern and computes 4 different environments. However, unit cell with repeated sites such as AB//BA are very common.

It is possible to hard code a bipartite IPEPS, however one can be slightly more ambitious and allow for any self-consistent unit cell pattern, such as ABC//BCA//CAB. The implementation can be made pretty simple. One needs to store unique site tensors in a vector and define getitem function to go back and forth between the unit cell coordinates and the internal 1D storage. The same accessors are used for the unique environment tensors.

As the CTMRG complexity is linear in the number of environments, making use of repetitions in the unit cell is a low hanging fruit. In my experience, it also improves stability and convergence.

[pbrehmer]

Thanks for for the suggestion, I'd really like to get that in in the near future! I was thinking a bit about how to implement this, given that the state and operator types like InfinitePEPS, InfinitePartitionFunction, etc. wrap around a Matrix.

• We could indeed instead wrap a Vector and define custom getitem functions depending on the underlying lattice. This might, however, result in a relatively big rewrite of the state and operator types and their user interfaces.
• Another option might be to keep the Matrix as the fundamental unit cell type but instead make certain elements of the matrix point to the same tensor. For example, an A B // B A sublattice would satisfy peps[1, 2] === peps[2, 1] and peps[1, 1] === peps[2, 2]. To take advantage of that in the actual CTMRG algorithms we could then iterate only over unique(peps.A) and unique(env.corners) and so on.

These are only loose thoughts but I do think we should be careful which route we choose because these are changes that might propagate quite a lot throughout the code. @lkdvos Any thoughts on this?

[lkdvos]

My initial idea was to just have a separate <:AbstractArray type for this that supports this functionality, and see how far I can get with that. In any case, making sure that there are not too many type restrictions in our code is a good thing, so I would want that if someone decided to define InfiniteStructuredPEPS that supports the same functionality as InfinitePEPS, this would "just work".

There is definitely a point to be made that this case is actually very common though, and obviously these are substantial speedups so there should be some use in looking into this.

[Yue-Zhengyuan]

Is the new LatticeArray (TiledArray) written for this purpose?

[lkdvos]

https://github.com/QuantumKitHub/PEPSKit.jl/tree/tiledarray

I did start working on some way of putting all of this together. It's far from finished, but I think I quite like the approach: it seems like it doesn't take too much alterations to have a generic tiling pattern, and as expected gives a linear speed up depending on the number of independent tensors. I'll see how far I get the coming days.