CTMRG on the triangular lattice

[sanderdemeyer]

Following a recent paper, we were thinking to implement this for PEPSKit. We implemented this already for TNRKit (see this PR, which still suffers from hopefully-soon-to-be-resolved LAPACK errors) for the C6v symmetric case and a trivial unit cell, but ideally we would like to have this in PEPSKit in a differentiable way for arbitrary unit cells, with and without C6v symmetry, and for both double-layer PEPS and PEPOTraces. This opens up a few questions.

• How do we go about implementing things for a triangular lattice? Some obvious questions like arrow conventions can be quite easily generalised from the square lattice (see e.g. the arrow convention in the TNRKit PR. For the x and y coordinates, I have a slight preference for the first direction pointing 60 degrees downward from the horizontal direction (i.e. pointing close to the SSE direction), and the second direction pointing east, since that is the convention I use for cluster expansions. But the discussion is of course open.) I know @lkdvos was working on something like LatticeArrays to deal with arbitrary lattices, but I don't know whether there's any progress on that since we last talked.
• The code in TNRKit is C6v symmetric (like its C4v symmetric counterpart on the square lattice). Having the non-symmetric version would also be nice, but maybe the ideal case would be to allow for both options. This could then also be done for the current square lattice implementation.
• We can define C6v and C4v symmetry for fermions in the case of a partition function, but (we think) not for the PEPS and PEPO cases. If we allow for both options, we can just throw an error whenever the symmetric version is not well-defined.
• I do not have much experience with making a CTMRG code differentiable, so any help would be greatly appreciated.

[lkdvos]

Apologies for the slow reply!

I'm obviously also interested in having such a method available for PEPSKit, although I do think that the wishlist of features you mention aren't necessarily straightforward 😁

• For the tensor conventions, I think we can revisit that discussion still, but my initial reaction would also be to stick as close as possible to the square lattice convention.
  I haven't looked at the TNRKit conventions, but given that we have either P <- N * E * S * W, or W * S <- N * E, I would probably have guessed P <- NW * NE * E * SE * SW * W or W * SW * SE <- NW * NE * E to be the closest to that (which also somewhat dictates the arrows, choosing the second form to not have any dual flags).
• For the lattice arrays, I fear I have not had the time to continue working on that a lot. I put in a bunch of effort trying to make tiled arrays work (i.e. things like [A B; B A]), and while I managed to get working CTMRG implementations for that which I was quite happy with, the compatibility with Zygote somewhat blew up in my face and got me a bit demotivated. See https://github.com/QuantumKitHub/PEPSKit.jl/tree/tiledarray for the (outdated) results of that.
• I'm definitely happy to have both a symmetric and non-symmetric version, and probably we should be investing some effort in the square lattice version of that too. I do like the TNRKit approach to simply define new structs and algorithms for this, so this might be something we can simply steal.
• I haven't given the fermions with C4v much thought, but I'm having a hard time imagining that this would be impossible (while I can fully see that it is hard, don't get me wrong!). Especially for the partition function case, there are no crossings, and in principle everything could be made planar and then this should be more or less equivalent to regular Z2 symmetry, so I would have to try and play around a bit more with this or hear your arguments about why you think it isn't possible.
• For the differentiable part, I'm not sure I can give that much great advise... It tends to be a big mix of rewriting code in very non-intuitive ways to avoid mutation, and a lot of trial and error. My workflow typically consists of simply running, inspecting the stacktrace, trying to figure out if this is something that has to be fixed or avoided, and repeating until it runs. Trying to split out smaller parts is of course very helpful, but I'm not sure I have better advice than that.

[sanderdemeyer]

• This is exactly the convention now in TNRKit, so perfect!
• If that is the case, we can always start by just defining the new tensors and algorithms for the triangular lattice, without any reference to a more general case. If/when there are more lattices, we can think a bit more about the way we want to generalize this.
• Defining different structs seems like the best option to me as well.
• If we have defined a partition function, it can indeed work (as showcased in the TNRKit implementation). It might just be rather hard to define a constraint on a PEPO/PEPS tensor for which the traced-out version / double-layer yields a C4v symmetric tensor. So probably, it's less useful in the fermionic case, but not necessarily ill-defined.
• Since I'm currently using it for finite-temperature calculations, I do not require it to be differentiable. Probably one day, someone will also want to use it for ground states, and then we can put in the work to make it differentiable. So maybe the best option is to leave it in TNRKit for the time being, and open a PR when we have the fully differentiable version, working for larger unit cells (and maybe even general unit cells like in LatticeArrays.

[Yue-Zhengyuan]

I kind of need honeycomb lattice as well. Simple update (and neighborhood tensor update) can be specialized for arbitrary unit cell, though native CTMRG contraction (without blocking sites) is still limited to a trivial unit cell (containing two sites; see this article).