Repository navigation
Initial enviroment tensors from the local tensors #136
Description
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.
Activity
Confusio commentedon Feb 22, 2025
I found that
env=CTMRGEnv(ones,ComplexF64,peps,spacetype(peps.A[1])(0=>1))does this job.lkdvos commentedon Feb 22, 2025
I think that option might be a bit limited depending on the symmetry, there are no guarantees that
0is actually the trivial charge (although it often is). The more generic option isoneunit(spacetype(...)), which should give you the desired result: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:
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 commentedon Feb 22, 2025
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 usingtruncdim(χ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 withtruncdim(χenv)can introduce a problem. In my case, I had to implement a custom two-round CTMRG optimization scheme (1st fortruncdim(χenv)and 2nd forFixedSpaceTruncation()). Since I am not entirely familiar with the OptimKit interface, I am still encountering some challenges.lkdvos commentedon Feb 22, 2025
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 commentedon Feb 23, 2025
Thanks for the suggestions and explanation!
In the case where you just want to contract a PEPS using
leading_boundaryone could just supply the initial environment of choice. I think aCTMRGEnv(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_envoption in thePEPSOptimizestruct 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 anCTMRGEnvInitializationalgorithm 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 commentedon Feb 23, 2025
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 algorithmsin the sense that you can do something likeDMRG2(; 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 commentedon Feb 23, 2025
For reference: https://github.com/QuantumKitHub/MPSKit.jl/blob/master/src/algorithms/unionalg.jl
pbrehmer commentedon Feb 24, 2025
Agree, I would first concentrate on providing these three options. To make it work during optimization, we could replace the
reuse_envfield inPEPSOptimizebyboundary_initialization::Iwith type parameterIwhich could beReuseEnv,RandomEnvorIsomorphismEnv(again names up for debate).The
UnionAlgway of combining algorithms is really neat, perhaps we could add that at a later stage (thinking of priorities).