[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 67.00680% with 194 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/states/infinitepepstriangular.jl	33.00%	69 Missing ⚠️
src/networks/infinitetriangularnetwork.jl	39.43%	43 Missing ⚠️
src/environments/ctmrg_environments_triangular.jl	73.23%	19 Missing ⚠️
src/networks/local_triangular_sandwich.jl	10.00%	18 Missing ⚠️
src/algorithms/ctmrg_triangular/utility.jl	61.11%	14 Missing ⚠️
src/algorithms/ctmrg_triangular/simultaneous.jl	93.95%	9 Missing ⚠️
src/networks/tensors_triangular.jl	18.18%	9 Missing ⚠️
src/algorithms/ctmrg_triangular/ctmrg.jl	84.84%	5 Missing ⚠️
src/algorithms/toolbox_triangular.jl	91.66%	5 Missing ⚠️
...rithms/optimization/fixed_point_differentiation.jl	0.00%	3 Missing ⚠️

Files with missing lines	Coverage Δ
src/PEPSKit.jl	100.00% <ø> (ø)
...thms/contractions/ctmrg_contractions_triangular.jl	100.00% <100.00%> (ø)
...rithms/optimization/fixed_point_differentiation.jl	93.92% <0.00%> (-1.59%)	⬇️
src/algorithms/ctmrg_triangular/ctmrg.jl	84.84% <84.84%> (ø)
src/algorithms/toolbox_triangular.jl	91.66% <91.66%> (ø)
src/algorithms/ctmrg_triangular/simultaneous.jl	93.95% <93.95%> (ø)
src/networks/tensors_triangular.jl	18.18% <18.18%> (ø)
src/algorithms/ctmrg_triangular/utility.jl	61.11% <61.11%> (ø)
src/networks/local_triangular_sandwich.jl	10.00% <10.00%> (ø)
src/environments/ctmrg_environments_triangular.jl	73.23% <73.23%> (ø)
... and 2 more

... and 2 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.

[github-actions]

Your PR no longer requires formatting changes. Thank you for your contribution!

[philihps]

Hi Sander, Lander, Lukas and collaborators,
What is the current status of the triangular CTMRG in PEPSKit? We have made some improvements to the variPEPS implementation. In particular, we can now avoid computing the second set of Q-projectors and construct the Ta/Tb tensors directly, saving three costly SVDs.
If that would be useful, I’d be happy to contribute to this PR and port these improvements to PEPSKit. Since I’m less familiar with the internals of PEPSKit and the related QuantumKitHub packages, I would use our robot friend to help with this. Of course I would review and test the changes and keep the scope focused. Is there any ongoing work on this that I should coordinate with?

[Yue-Zhengyuan]

Pinging @sanderdemeyer @pbrehmer @leburgel in case you missed @philihps's message.

[sanderdemeyer]

Hi Philipp,

We have a working implementation in TNRKit (see c6vctm_triangular.jl and ctm_triangular.jl here) for a single-layer partition function, which we implemented to calculate finite-temperature observables. In this PR, we wanted to extend it to the more general case of a non-trivial unit cell, together with a double-layer implementation that we can perform AD on to find ground-state energies. My attention diverted to other projects for a while, but I would still find it very cool to have the more efficient implementation that you propose. In that regard, it would make more sense (I think) to first implement your improvements for the single-layer case in TNRKit.jl, see that everything works the way we expect it to, and then move it to this PR, where we will then finalise the AD stuff and make everything compatible with the internals of PEPSKit.

Do you have some notes on these improvements, or are you willing to have a quick Zoom call about this?

[philihps]

Hi @sanderdemeyer, the C6v-symmetric version of the classical partition function should not be any more efficient with the modified implementation, since there is only one pair of Ta/Tb tensors that need to be decomposed. However, it would simplify the code slightly. The main benefit would be for the double-layer PEPS version, where only three Ta/Tb pairs would need to be decomposed instead of the six required when using the Q-projector formulation. I am happy to discuss this with you over Zoom, I will send you an email.