CTMRG support for PEPS-PEPO-PEPS networks

[leburgel]

Implements all the contractions required to run CTMRG for PEPO sandwiches with an arbitrary number of layers.

TODO:

• Add a test with a proper numerical check on the outcome

[codecov]

Codecov Report

Attention: Patch coverage is 59.77961% with 146 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/contractions/ctmrg_contractions.jl	52.72%	139 Missing ⚠️
src/algorithms/contractions/vumps_contractions.jl	75.00%	5 Missing ⚠️
src/algorithms/ctmrg/gaugefix.jl	87.50%	1 Missing ⚠️
src/networks/infinitesquarenetwork.jl	0.00%	1 Missing ⚠️

Files with missing lines	Coverage Δ
src/algorithms/contractions/localoperator.jl	94.94% <ø> (-0.25%)	⬇️
src/algorithms/toolbox.jl	98.07% <100.00%> (+15.46%)	⬆️
src/algorithms/ctmrg/gaugefix.jl	97.19% <87.50%> (-0.81%)	⬇️
src/networks/infinitesquarenetwork.jl	50.58% <0.00%> (-0.61%)	⬇️
src/algorithms/contractions/vumps_contractions.jl	75.40% <75.00%> (+48.52%)	⬆️
src/algorithms/contractions/ctmrg_contractions.jl	58.09% <52.72%> (-4.84%)	⬇️

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[leburgel]

I just blindly implemented all the contractions in the ctmrg_contractions.jl file, but it seems like quite a few of the methods are never used. Maybe this would also be a good point to do some housekeeping with regard to what we should keep around and what not?

[pbrehmer]

Looking at the code coverage, it seems that some contractions in ctmrg_contractions.jl got obsolete by adding the sparse EnlargedCorner struct which handles the row-column indices such that the row-column contraction methods are not used anymore (enlarge_northwest_corner and so on). In my opinion we can get rid of them. If we agree on this, I can get rid of the corresponding methods.

Some of the contractions (left_projector, right_projector, some half_infinite_environment, renormalize_northwest_corner, ...) are not yet tested because sparse CTMRG (never explicitly constructing enlarged corners and full environments) is not yet fully implemented due to the complicated KrylovKit/TensorKit SVD interplay. But the building blocks are already there and the rest will be added in the future.

And for some contractions I don't yet get why codecov is flagging them as untested, so perhaps these are false flags or I need to dig deeper?

[leburgel]

Removing the row-column-style enlarged corner methods seems good, it seems unlikely we would go back to using these. For the sparse CTMRG contractions, I guess it's fine to leave them as is then and reassess coverage once the things are actually implemented. Otherwise we would essentially be commenting them now and uncommenting them later, which is also a bit silly.

[leburgel]

In terms of timeline, when do you think it would be good to try and add this @lkdvos @pbrehmer? It's not really urgent, but it's also quite orthogonal to most other things being worked on so I wouldn't mind getting this in sooner rather than later. The reason I'm asking is because I was hoping to update some bits to work with fermions, starting with the boundary MPS code, and it would be more efficent to have this in before I start that.

[pbrehmer]

It does seem that this PR is relatively decoupled from the rest and that it might be finished soon? So I would be fine with still getting this in for v0.5 (in roadmap terms). Actually, it would be nice to have a little PEPO example in the docs anyway. If you think the PR can be realistically finished soon, then go for it, I'd say :-) But that also of course depends on the review capacities since we have quite a few PRs in the pipeline...

[leburgel]

From my end I think this is finished and ready for review, I was more asking about review capacity since there's a lot of things going on. I would have liked to improve coverage, but since there's a lot of contractions that will only be used when sparse CTMRG is implemented that's not really possible right now I think. I also don't feel like leaving out those contractions now and implementing them later, just because it might take me some time to remember how these worked as it's a bit involved in places :)

The test can easily be made into an example for the documentation when we get to adding more examples, I quite like it.

[pbrehmer]

Sounds great! I won't be able to take a look today but I could review tomorrow (if we want to)

[lkdvos]

Left some small comments, otherwise I'm also okay with merging this.

[lkdvos]

approved as soon as tests actually work :)