Generalization of the CTMRG state type

[pbrehmer]

Currently, CTMRG only runs on InfinitePEPS as its state type, and with #111 also on InfinitePartitionFunctions. However, all CTMRG contractions as well as the sparse storage structs in principle support more general objects, such as PEPS-PEPS or PEPS-PEPO-PEPS sandwiches.

In order to generalize the state type that is specified by the user and passed on to leading_boundary we need to agree on a design. Looking at the implementation of CTMRG, it is clear that the type of state needs to support indexing operations and rotations. I think there are at least two options:

1. We could create a PEPSSandwich and PEPOSandwich type. Here the question would be if they should be subtyped as an InfiniteSquareNetwork - this would however somehow create a circular hierarchy in its current state.
2. We could just use tuples of InfiniteSquareNetworks to represent the sandwiches, e.g. Tuple{InfintePEPS,InfinitePEPS}, and define indexing methods such as getindex on them.

Another thing to consider is to relax the InfiniteSquareNetwork interface such that it is understood as an interface which states that can be contracted using CTMRG should support. This would e.g. mean getting rid of the math and OptimKit operations.

See #111 for further comments.

[lkdvos]

Just to make a comment here, I think there are two separate issues you are touching upon.

The first is about data structures, in the sense of how we actually lay out the data as julia structs. There are many options, using tuples or custom structs, and my guess is that the performance implications are completely negligible, so I would just choose the thing that is most easy to interpret as a human. In other words, whatever is the most intuitive for each specific instance should be fine.

A second point is about designing functions. Here, it is a very common pitfall to think in terms of abstract types and type hierarchies, which is I fear somewhat the direction this question is pushing towards. Very often, prematurely restricting the type signature of functions leads to bad code architectures, since you then are effectively designing code around objects. Julia often shines best by not thinking about the data structures at all, and simply ducktyping everything. This means that rather than thinking about what types of arguments the CTMRG routine should accept, it is a lot better to think about what functions the arguments should support.

TLDR: instead of trying to fit everything into abstract types, I would focus more on trying to avoid specializing methods as much as possible, especially the higher level parent methods and only doing that whenever the actual layout of an object is known, writing concrete implementations for leaf methods. That way, we can decide on future additions in the future, and simply implement only the leaf methods whenever needed.

[lkdvos]

Also linking #113 here since that is very much related. I have no problems with having an abstract supertype, but we don't actually need a supertype to avoid code duplication, and simply write many of the functions without restrictions on the signature

[leburgel]

To be able to run CTMRG on something, we just need it to be a 2D rectangular network which has an 'effective rank-4 tensor' at every site in its unit cell, i.e. something that can be contracted as if it's essentially a square rank-4 tensor. When just considering what kind of arguments each method needs to take, it doesn't seem very natural to me to define our contractible objects using an abstract supertype and then placing different sandwiches under this, or even to think of them as different kinds of tuples for every type of sandwich. Our type for 'contractible networks' could just be something that wraps a matrix, where each entry of that matrix is rank-4-like. In other words, just thinking of a network of tensor sandwiches, instead of a sandwich of 'state' networks. If we want, the contractible supertype could then just be a single concrete type on which all the relevant indexing methods are defined, with a type parameter encoding the type of local sandwich it consists of (if this is even needed).

Then we could decouple our physics-inspired tensor networks (InfinitePartitionFunction, InfinitePEPS, InfinitePEPO, i.e. the subtypes of the current InfiniteSquareNetwork) from our contractible objects a bit, and just add a syntax layer that appropriately converts (combinations of) these InfiniteSquareNetworks to the appropriate contractible object.

All the leaf methods only really care about which kind of local sandwich they get, since this determines the actual contractions to be done. Again we could do this by introducing some abstract local sandwich supertype, but purely for dispatch we could just as well use tuples as long as we're clear about our conventions here.

I know this is quite different from say the current boundary MPS approach where things like InfiniteTransferPEPS and InfiniteTransferPEPO are different structs, but given that the actual contraction methods only specialize on the type of local sandwich, e.g.

PEPSKit.jl/src/operators/transferpepo.jl

Lines 110 to 115 in 69ae4d3

	function MPSKit.transfer_left(
	GL::GenericMPSTensor{S,N},
	O::Tuple{T,T,Tuple{Vararg{P,H}}},
	A::GenericMPSTensor{S,N},
	Ā::GenericMPSTensor{S,N},
	) where {S,T<:PEPSTensor,P<:PEPOTensor,N,H}

it would have probably made more sense to use a single transfer matrix type where it's local entries encode what needs to be done.

[lkdvos]

Considering that last point, it definitely does, and that's what MPSKit is migrating towards anyways. It used to be the case that there were multiple InfiniteMPO types with an abstract supertype, but now InfiniteMPO is simply a vector of objects that represent a local MPO tensor, and everything is dispatched through to the lower levels.