add Triangular CTMRG

[sanderdemeyer]

This code is based on its (asymetric) implementation in TNRKit.jl TNRKit.jl, which was based on this paper.

This is definitely still a work in progress. Some major comments are in order.

• There are many convention choices that are up for debate. I think the current choice for the order of the legs is a natural extension to the square case.
• Naming conventions are also up for debate.
• Not everything is as general as the square lattice case. E.g. some constructors can definitely still be improved.
• There is no triangular PEPO constructor yet. I don't need it for this PR, so to make this PR somewhat manageable, I would prefer to keep it out for now and add it later when someone needs it.
• There are some docstrings that need to be fixed. The definition of the triangular environment (which can be found in the paper) still needs to be drawn.
• Maybe the most important comment of all is in terms of differentiability. The tests are currently failing for the differentiability part (as expected). I know that @pbrehmer was willing to help out for this. In any case, any help on this part would definitely be appreciated. If this would be fixed, we could also calculate the ground-state energy of some interesting model (which was the whole point of this PR), which could be used as a test.

[kshyatt]

@sanderdemeyer maybe this would be a good forcing function for #323 ?

[codecov]

Codecov Report

❌ Patch coverage is 0% with 388 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/triangular_ctmrg/simultaneous.jl	0.00%	191 Missing ⚠️
src/networks/infinitetriangularnetwork.jl	0.00%	71 Missing ⚠️
src/algorithms/triangular_ctmrg/utility.jl	0.00%	34 Missing ⚠️
src/algorithms/triangular_ctmrg/ctmrg.jl	0.00%	33 Missing ⚠️
src/environments/ctmrg_tria_environments.jl	0.00%	26 Missing ⚠️
src/networks/local_triangular_sandwich.jl	0.00%	20 Missing ⚠️
src/networks/tensors_tria.jl	0.00%	11 Missing ⚠️
src/algorithms/select_algorithm.jl	0.00%	2 Missing ⚠️

Files with missing lines	Coverage Δ
src/PEPSKit.jl	100.00% <ø> (ø)
src/algorithms/select_algorithm.jl	23.07% <0.00%> (-51.93%)	⬇️
src/networks/tensors_tria.jl	0.00% <0.00%> (ø)
src/networks/local_triangular_sandwich.jl	0.00% <0.00%> (ø)
src/environments/ctmrg_tria_environments.jl	0.00% <0.00%> (ø)
src/algorithms/triangular_ctmrg/ctmrg.jl	0.00% <0.00%> (ø)
src/algorithms/triangular_ctmrg/utility.jl	0.00% <0.00%> (ø)
src/networks/infinitetriangularnetwork.jl	0.00% <0.00%> (ø)
src/algorithms/triangular_ctmrg/simultaneous.jl	0.00% <0.00%> (ø)

... and 31 files with indirect coverage changes

🚀 New features to boost your workflow:

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

[Yue-Zhengyuan]

A suggestion for file names: I prefer ctmrg_environment_triangular etc so that when sorting files by name, same things for different lattices appear together (infinite_triangular_network is an exception because infinite_square_network existed).

[pbrehmer]

Thanks for the great work! I have a couple of general comments/suggestions:

• Can we put all contractions into separate files in an algorithm-specific directory, e.g. algorithms/contractions/triangular_ctmrg/? That's what we also do for the other algorithms.
• Regarding the contractions themselves: We try to label the tensor indices according to the convention that physical indices are labelled starting with d , virtual PEPS bonds with D, environment bonds with \chi, and then end with the direction they are connecting to.
• How do you feel about naming the algorithm struct Triangular(Simultaneous)CTMRG (I think the simultaneous might be redundant?) instead of SimultaneousCTMRGTria? I think I'd prefer writing it out instead of having the "tria" abbreviation. (Similary for other things named with "tria".)
• Regarding differentiability: There are currently great efforts to make PEPSKit compatible with Mooncake which supports mutation and is better than Zygote in many other ways. It would probably be worth it to wait (not that long) until Mooncake is supported and then make the triangular CTMRG routine differentiable. It would make life easier in general and also not require all these weird modifications that were introduced due to Zygote. To make things more manageable, in this PR, we could first implement only the forward pass/contraction algorithm and then make things differentiable/optimizable in another PR. What do you think?

I'll try to go over the code soon and give more specific suggestions then.