Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEPSHamiltonian Refactor #49

Merged
merged 42 commits into from
Jul 9, 2024
Merged

PEPSHamiltonian Refactor #49

merged 42 commits into from
Jul 9, 2024

Conversation

lkdvos
Copy link
Member

@lkdvos lkdvos commented Jul 2, 2024

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
Copy link
Collaborator

pbrehmer commented Jul 2, 2024

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.

src/operators/models.jl Outdated Show resolved Hide resolved
@lkdvos lkdvos changed the base branch from master to archive July 3, 2024 09:05
@lkdvos lkdvos changed the base branch from archive to master July 3, 2024 09:05
Copy link

codecov bot commented Jul 3, 2024

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
Copy link
Member Author

lkdvos commented Jul 4, 2024

I think this should do the trick :)

@pbrehmer
Copy link
Collaborator

pbrehmer commented Jul 4, 2024

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
Copy link
Member Author

lkdvos commented Jul 4, 2024

Macros are hard...

@lkdvos
Copy link
Member Author

lkdvos commented Jul 8, 2024

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
Copy link
Collaborator

pbrehmer commented Jul 8, 2024

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
Copy link
Member Author

lkdvos commented Jul 8, 2024

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
Copy link
Member Author

lkdvos commented Jul 9, 2024

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

@lkdvos lkdvos enabled auto-merge (squash) July 9, 2024 12:59
@lkdvos lkdvos requested a review from pbrehmer July 9, 2024 12:59
Copy link
Collaborator

@pbrehmer pbrehmer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 :)

@lkdvos lkdvos merged commit 53e53aa into master Jul 9, 2024
8 of 9 checks passed
@leburgel leburgel deleted the ld-expval branch July 9, 2024 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants