PEPSHamiltonian Refactor

[lkdvos]

This PR refactors the operator construction. It consists of a couple parts that I think will make it nice to work with generic operators:

Generic contractions

I bit the bullet and just wrote some generic contraction routines for arbitrary interactions. These are captured in the functions contract_localoperator and contract_localnorm, which take N coordinates and a AbstractTensorMap{S,N,N}, and generates code for contracting them. It's using TensorOperations' functionality to optimize the contraction order, and in principle could work for arbitrary ranges, but probably at some point either the contraction order optimizer will become prohibitively expensive, or the contraction will.
Highlights here are the fact that this means we can also do J1J2 models, or even plaquette operators.

PEPSHamiltonian

Because of the way the generic contractions work, all we really need to define a hamiltonian term is a set of indices and an operator. Thus, I wrote a simple wrapper PEPSHamiltonian, which just represents a tuple of these terms. I think it will be convenient in the future to have a field lattice, which is just an array of the physical spaces upon which it acts. This struct will silently assume to act as the identity on all sites that are not present, and as such it can be useful to know what spaces these are (for example if we would like to initialize a peps for such an operator)

There's definitely a lot of things that can still be added, from convenience methods such as +(PEPSHamiltonian, PEPSHamiltonian) etc, to convenience constructors such as next_nearest_neighbour, and I am missing a bit of documentation and docstrings still, but I already procrastinated a bit too much so I was hoping to give this as an initial launch.
@pbrehmer , it might be nice to couple this with the new re-ordering of the coordinates for the environments. I currently wrote this with the old convention, just to make everything work and because I wasn't entirely sure what we settled on, but it should be relatively straightforward to change these offsets. Do you want to look into this?

[pbrehmer]

Thanks for the rewrite, it looks quite amazing at first glance!

I currently wrote this with the old convention, just to make everything work and because I wasn't entirely sure what we settled on, but it should be relatively straightforward to change these offsets.

I can definitely adjust all the indices to the new convention, that shouldn't be too much work. I'll take a look tomorrow.

[codecov]

Codecov Report

Attention: Patch coverage is 88.58268% with 29 lines in your changes missing coverage. Please review.

Files	Coverage Δ
src/PEPSKit.jl	100.00% <ø> (ø)
src/operators/models.jl	100.00% <100.00%> (ø)
src/operators/transferpepo.jl	48.05% <100.00%> (-1.95%)	⬇️
src/operators/transferpeps.jl	78.57% <100.00%> (-1.43%)	⬇️
src/utility/symmetrization.jl	67.04% <ø> (+2.04%)	⬆️
src/states/infinitepeps.jl	65.75% <80.00%> (-7.11%)	⬇️
src/operators/infinitepepo.jl	18.86% <0.00%> (-1.14%)	⬇️
src/states/abstractpeps.jl	70.00% <50.00%> (-30.00%)	⬇️
src/algorithms/ctmrg.jl	94.68% <91.83%> (+0.05%)	⬆️
src/operators/localoperator.jl	94.00% <93.91%> (+19.92%)	⬆️
... and 1 more

... and 2 files with indirect coverage changes

[lkdvos]

I think this should do the trick :)

[pbrehmer]

So I now added @autoopt to all CTMRG contractions but I now get weird errors, where I'm not sure why and where the macros causes that. For example, if I try to run the heisenberg.jl example, the leading_boundary call will lead to the following:

ERROR: UndefVarError: `edge_W` not defined
Stacktrace:
 [1] southwest_corner(edge_S::TrivialTensorMap{…}, corner_SW::TrivialTensorMap{…}, edge_W::TrivialTensorMap{…}, peps_above::TrivialTensorMap{…}, peps_below::TrivialTensorMap{…})
   @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/ctmrg.jl:408
 [2] southwest_corner
   @ ~/repos/PEPSKit.jl/src/algorithms/ctmrg.jl:408 [inlined]
 [3] left_move(state::InfinitePEPS{TrivialTensorMap{…}}, env::CTMRGEnv{TrivialTensorMap{…}, TrivialTensorMap{…}}, alg::CTMRG)
   @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/ctmrg.jl:320
 [4] ctmrg_iter(state::InfinitePEPS{…}, env::CTMRGEnv{…}, alg::CTMRG)
   @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/ctmrg.jl:290
 [5] leading_boundary(envinit::CTMRGEnv{…}, state::InfinitePEPS{…}, alg::CTMRG)
   @ PEPSKit ~/repos/PEPSKit.jl/src/algorithms/ctmrg.jl:41
 [6] top-level scope
   @ ~/repos/PEPSKit.jl/test/heisenberg.jl:24
Some type information was truncated. Use `show(err)` to see complete types.

Clearly, edge_W is defined since it just is the function argument. @lkdvos Do you have an idea what might be happening?

[lkdvos]

Macros are hard...

[lkdvos]

What's the status on this PR right now? Are there still things we need to do, or is it just a matter of stabilizing the tests a bit?

[pbrehmer]

Yes, I think when the tests run through, this should be mergeable (at least from my side).

Regarding the tests: on the new version of MPSKit (on the other PR), the VUMPS "(2, 2) PEPS" was spitting out a lot of imaginary warnings and the results came out a bit too wrong (had to increase the tolerance quite a bit). So maybe that needs some stabilizing.

[lkdvos]

I'll fix that tomorrow. The new version of Krylovkit allows us to use lanczos for hermitian systems because it warns instead of errors, so the default there got switched to lanczos. PEPS transfer matrices are just typically not hermitian, hence the problems. It's just a matter of switching back to Arnoldi

[lkdvos]

Ok, I'm hoping this should now be fixed, so once the tests turn green this is good to go for me.
The warnings with the mpskit loggers is something I'll fix on the MPSKit side of things, so this should be automatically inherited after I tag a new release there

[pbrehmer]

Looks lovely to me! I guess the index convention thing in derivatives.jl, transferpepo.jl and transferpeps.jl is not super important for now, so I think we should merge :)