Initial enviroment tensors from the local tensors

[Confusio]

Currently, PEPSKit initializes the environment’s corner and edge tensors randomly. However, I have found that this random initialization often leads to poor convergence—especially when working with symmetric tensors. In my experience, initializing these tensors by contracting the extra virtual legs from the bra and ket local tensors significantly improves convergence. It would be very useful if PEPSKit offered an option to use this improved initialization method, so I wouldn’t have to study the code in detail and implement it myself.

[Confusio]

I found that env=CTMRGEnv(ones,ComplexF64,peps,spacetype(peps.A[1])(0=>1)) does this job.

[lkdvos]

I think that option might be a bit limited depending on the symmetry, there are no guarantees that 0 is actually the trivial charge (although it often is). The more generic option is oneunit(spacetype(...)), which should give you the desired result:

env = CTMRGEnv(ones, scalartype(peps), oneunit(spacetype(peps))

This however doesn't fully achieve what you are hinting at, since it is not actually an "identity" on the virtual legs of the PEPS, it is a matrix filled with ones (which is an identity only if it's of size 1x1, but perhaps is close enough to an identity otherwise).

We could consider supporting/extending something like this as well, although as usual coming up with a good interface is the hard part.
Maybe this could work:

function CTMRGEnv(isomorphism, ::Type{T}, ::InfinitePEPS)
    # body
end

I'd be very happy to hear if you have any suggestions about a good interface, or function name for this, and I'll gladly add it.

(I'll reopen this issue to remind myself this is not yet done)

[Confusio]

Hi Lukas, glad to see your reply. Following is my suggestion:

Proper initialization of the boundary corner and edge tensors is critical for CTMRG convergence. In my experience, initializing these boundary tensors directly from the PEPS tensors is preferable, as it reflects the physical picture of a finite lattice with open boundary conditions—where the boundary is nearly approximated by the bulk. Therefore, I propose introducing a method "alg" to specify the initialization type for the boundary tensors. Although there are already too many "alg"s, the boundary tensor initialization deserves its own "alg".

Another important aspect is the truncation scheme used for the boundary tensors. The default choice is FixedSpaceTruncation(), but this is not generally optimal. For example, in SU(2)-symmetric PEPS, it is often unclear which spin multiplicities should be taken. In practice, I initially set the truncation dimension using truncdim(χenv) for the first round of CTMRG. However, when applying a fixed-point AD, the boundary tensor space must remain constant, and dynamically adjusting the dimension with truncdim(χenv) can introduce a problem. In my case, I had to implement a custom two-round CTMRG optimization scheme (1st for truncdim(χenv) and 2nd for FixedSpaceTruncation()). Since I am not entirely familiar with the OptimKit interface, I am still encountering some challenges.

[lkdvos]

I've opened a separate issue for that, which I think we can also resolve. Thanks for bringing these up, this should overall improve everyone's experience with this package.

[pbrehmer]

Thanks for the suggestions and explanation!

Therefore, I propose introducing a method "alg" to specify the initialization type for the boundary tensors. Although there are already too many "alg"s, the boundary tensor initialization deserves its own "alg".

In the case where you just want to contract a PEPS using leading_boundary one could just supply the initial environment of choice. I think a CTMRGEnv(isomorphism, ::Type{T}, ::InfinitePEPS) constructor should be enough to achieve what you suggested.

In case of optimizing a PEPS, a new alg might be an option: Currently, we have the reuse_env option in the PEPSOptimize struct which is used to initialize the environment at a given optimization step on the converged environment of the previous optimization step. Here, we could think about introducing an CTMRGEnvInitialization algorithm struct (there's probably a better name) which handles all these initialization cases. There we could have an option for initializing on the contracted ket-bra tensors, for reusing environments from previous steps and for mixed things like initializing the environment in the first 10 steps (or until a gradient tolerance is passed) one way and then opting for reusing environments.

However, I'm not sure if it makes more sense to implement an algorithm supertype where the subtypes are these different options or to have one algorithm struct which combines all these options in different fields.

[lkdvos]

In any case, we could start by providing some implementations, even when there is no "algorithm" to control that behavior it seems indeed like a reasonable thing to want to control.
It seems to me like there are only 3 options anyways at the moment: random, isomorphisms, or reusing previous environments.

As an alternative that might also help, in MPSKit we support multiple algorithms in the sense that you can do something like DMRG2(; maxiter=10) & DMRG(; tol=1e-10) to achieve a sequential two-site update to change bond dimensions, followed by single-site updates to obtain convergence. By having the options to have two CTMRG algorithms sequentially, we could have an initial phase where the bond dimensions are not fixed, followed by a fixed phase.

[lkdvos]

For reference: https://github.com/QuantumKitHub/MPSKit.jl/blob/master/src/algorithms/unionalg.jl

[pbrehmer]

Agree, I would first concentrate on providing these three options. To make it work during optimization, we could replace the reuse_env field in PEPSOptimize by boundary_initialization::I with type parameter I which could be ReuseEnv, RandomEnv or IsomorphismEnv (again names up for debate).

The UnionAlg way of combining algorithms is really neat, perhaps we could add that at a later stage (thinking of priorities).