[WIP] Environment initialization for CTMRG

[leburgel]

Attempt at some better environment initialization routines for CTMRG. Should solve #255 once it's finished and documented.

This implements an initialize_environment method which initializes a CTMRGEnv for a given network according to a specific InitializationStyle. I specified three kinds of InitializationStyles: RandomInitialization for initializing a random environment, ProductStateInitialization for initializing a (potentially embedded) product state environment, and ApplicationInitialization which grows an initial environment from a product state according to a given truncation scheme. Names, arguments and which ones are optional for discussion, but at least this already handles the test case from #255 in a fairly straightforward way.

[codecov]

Codecov Report

❌ Patch coverage is 61.97183% with 27 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/environments/product_state_environments.jl	52.00%	24 Missing ⚠️
src/algorithms/ctmrg/initialization.jl	87.50%	2 Missing ⚠️
src/utility/util.jl	80.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/utility/util.jl	69.38% <80.00%> (+0.57%)	⬆️
src/algorithms/ctmrg/initialization.jl	87.50% <87.50%> (ø)
src/environments/product_state_environments.jl	52.00% <52.00%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Yue-Zhengyuan]

I just noticed one more way to initialize the environment (I already have some code on this in my neighborhood tensor update branch), which we may call Neighbo(u)rhoodInitialization. This was mentioned in 1104.5463:

Initially, the corner and edge tensors at position [x,y] are constructed similarly as a reduced tensor a[x,y], by multiplying the tensor A[x,y] to its conjugate and fusing the bond indices,9 where we trace over the legs directed toward an open boundary.

For example, an edge tensor is constructed like this:

           2    
         ╱      
┌-----ket----- 4
|    ╱ |        
|   6  |   1    
|      | ╱      
└-----bra----- 3
     ╱          
    5           

In this way, the initialized environment directly have boundary dimension $\chi = D^2$.

Recently I realized that having a good initialization is also important during full update. Right now, I'm using the environment from the last iteration as initialization for the next step. But sometimes even this doesn't work well. So I kind of hope that we can finish this PR soon.

[lkdvos]

Would this give a different result from starting from environments that are the identity and doing a single step of ctmrg without truncating?

[Yue-Zhengyuan]

Nice insight, they may indeed be the same thing... for fermions we may need to further ensure that the twists are correctly added.

[Yue-Zhengyuan]

We definitely need a test with fermionic iPEPS on this, in case parity-odd elements become -1 due to twists.

[leburgel]

Given the fact that this PR might be useful for #321, I'll try to pick this up again now. However, considering the original purpose, the review comments, and the new use case in #321, it's not entirely clear to me where to go with this. Let me try to summarize.

The original motivation for this PR was to solve #255, by making it 'easy' to initialize a CTMRG environment with a given bond dimension/virtual space by growing it from a smaller environment (with a product state being the default starting point. Basically, package up what people do all the time in a single method. The easiest way to do this would be to write a specialized initialize_ctmrg_environment.

However, since initializing environments is something very common, I tried to make it a bit more generic so that the same signature and initialization flavors could be reused in other places. This came out a bit awkward right away, as can be seen from the review comments. A first obvious problem is that the specification of virtual environment spaces really depends on what exactly we're doing, which gives rise to some awkward argument orderings. In addition, to actually 'grow' an environment we need to apply a few iterations of an algorithm (see ApplicationInitialization), which requires some algorithm settings to be specified. Again, this all made sense in the context of the original application to CTMRG, but looks very arbitrary when seen in a generic context.

Now in #321 there's an additional aspect, where we actually want to initialize a different kind of environment depending on the contraction algorithm we use. For now the C4v implementation uses the normal CTMRGEnv struct, but it would probably make more sense to use a custom C4vCTMRGEnv. Anticipating that we also want to support boundary MPS contractions soon™, this gives more different environment types for more contraction algorithms.

Trying to consider all of this feels a bit annoying, which is also why this PR got completely stalled in the first place. To get this moving, I think the first thing to decide is whether we want to solve the whole (potentially still growing) problem here, or we first just address the original issue #255.

To address the original problem, I would switch to just writing an initialize_ctmrg_environment with the minimal functionality required to address the issue.

To go for a full generic initialize_environment, I think it becomes inevitable to include an actual contraction algorithm instance in the arguments. Either this, or an equivalent named tuple that can identify multiple different contraction algorithms (and not just flavors of CTMRG like we support now). That would lead to something like

initialize_environment([T,] network, contraction_algorithm, initialization_style, virtual_space_specification)

for the generic case withing PEPSKit.jl alone. The question then becomes if this is compatible with other kinds of environment initializations (e.g. in MPSKit.jl), and if we still want it to be.

Asking for any and all opinions from @lkdvos, @pbrehmer and @Yue-Zhengyuan, after which I'll have a go at getting this to a point where it's usable.

[Yue-Zhengyuan]

I applied ProductStateInitialization to finite-T SU tests.

[leburgel]

Kind of starting over on this one, hopefully I can work toward something useful that can be merged soon.

I'm giving up on trying to fit everything into a single initialize_environment method that works for all algorithms, and focusing on first writing a specific initialize_ctmrg_environment that solves the issue that actually motivated this PR in the first place.

Currently I have three initialization styles in mind that are useful:

• RandomInitialization: initializes a random CTMRGEnv with gives virtual spaces, essentially coinciding with the current default constructor.
• ProductStateInitialization: initializes a CTMRGEnv with trivial one-dimensional virtual spaces, corresponding to a product state environment to which we add trivial virtual legs.
• ApplicationInitialization: initializes a CTMRGEnv by applying a single CTMRG iteration to a (optionally) given product state environment, giving an environment with a bond dimension $D^2$.

These should solve both #136 and #255 already, without considering how to use this in optimization for now. In particular, none of these take a contraction algorithm as an input, which means we can avoid the nightmare of plumbing in all possible configurations. Any additional steps needed for initialization should then just be handled by the user.

These last two initialization styles make use of a product state environment as an intermediate step, where especially for the ApplicationInitialization one might want to manually choose a specific product state as a boundary condition. Therefore, it seemed useful to me to introduce a dedicated ProductStateEnv to represent product state environments. In particular, I think we want this to work for general InfiniteSquareNetworks. This means I can't just repurpose BPEnv, which is just exactly a product state environment with some extra structure.

To push this over the line, I'm planning to

• Replace BPEnv with a more general ProductStateEnv, and update all corresponding code.
• Add additional initialization methods specifically for PEPS overlaps, in particular an initialization from a product state where the tensors are identities between the "ket" and "bra" PEPS virtual spaces.

[leburgel]

Forgot about this, again.

With another remarkable delay, I added an option to use ProductStateInitialization(bipartite_id) specifically for two-layer InfiniteSquareNetworks (i.e. PEPS overlaps) which does exactly what @Yue-Zhengyuan suggested above and was already suggested in #136.

I picked the name bipartite_id because it kind of sounds like what it should do, even though it returns a (2, 0) tensor and not a (1, 1) linear map. I also exported it, because this seems like something people will want to use. Any suggestions on the name and whether or not it's a good idea to export are very welcome.

This definitely needs an example showcasing the different options. But I don't really have time to write one now, maybe it's best to just add the implementation already.

The final thing I still wanted to do was to try and replace BPEnv by the more general ProductStateEnvironment completely, and adding dispatch blockers on anything that requires a two-layer structure. It seemed a bit silly to me to keep both of these around, since they are essentially just the same thing. I had a look at this, and while it's definitely possible it feels like quite a bit of work so I didn't get to that. However, removing BPEnv is very much breaking, and we're just about to release v0.8.0. So I wanted to check opinions:

• Do we spend the time completely rewrite BP in terms of ProductStateEnv, and remove BPEnv before tagging v0.8.0?
• Or do we just keep both around for now, and save a rewrite for later? This choice could be relevant for (feat) Simple update using BP environments #372 as well, since we might be able to implement everything in terms of a single environment type?

Any thoughts, @Yue-Zhengyuan @lkdvos?

[Yue-Zhengyuan]

Some small comments.

Do we spend the time completely rewrite BP in terms of ProductStateEnv

I'm in favor of this, since I feel that BPEnv and ProductStateEnv are (exactly?) the same thing, with the renaming BPEnv.messages to ProductStateEnv.edges.

[Yue-Zhengyuan]

Typo: componens

The word "bipartite" is a bit ambiguous here. Until now it means the checkerboard lattice structure with 2 independent tensors.

Here, by "between two componens of a bipartite product space" do you mean "between two layers of a two-layer network"?

[Yue-Zhengyuan]

Better to add docstrings to describe what each InitializationStyle is actually doing, especially ApplicationInitialization whose behavior is not obvious by just looking at the name.

[Yue-Zhengyuan]

It might be helpful not to restrict env0 to be a ProductStateEnv. For example, one may start from any CTMRGEnv with a small bond dimension, and do one step of CTMRG. But the current approach is also fine if you don't want too much freedom.