(feat) Simple update using BP environments

[lkdvos]

This is a (long-overdue) addition that might be relevant for #361, where I implemented (up to nearest neighbour) simple update with the BPEnv instead of the SUWeight.
This is definitely still WIP for now, but I thought I'd already open the PR so we might be able to compare performances, and I could get some feedback from @Yue-Zhengyuan and @ogauthe on that.

To do

• Implement surrounding plumbing for repeated action etc
• Implement core for state::InfinitePEPO
• Implement core for next-nearest-neighour

[codecov]

Codecov Report

❌ Patch coverage is 1.47059% with 134 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/algorithms/bp/simpleupdate.jl	0.00%	119 Missing ⚠️
src/environments/bp_environments.jl	11.76%	15 Missing ⚠️

Files with missing lines	Coverage Δ
src/environments/bp_environments.jl	32.23% <11.76%> (-57.20%)	⬇️
src/algorithms/bp/simpleupdate.jl	0.00% <0.00%> (ø)

... and 42 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]

I think SU with BPEnv (which consists of generic TensorMap{1, 1}s) should be strictly less efficient than SU with SUWeight (which consists of DiagonalTensorMaps). If using BPEnv turns out to be faster, it only means current SU implementation can be further improved.

For Trotter-based time evolution, what will be interesting is using BPEnv to construct bond environments more accurate than SUWeight. For example, YASTN now has a hybrid of NTU and BPEnv. Alternatives may include loop series expansion and a generalized BP.

[lkdvos]

I think I am indeed more interested in the improved accuracy possibility, I would be surprised if the diagonal parts are really dominant.
In principle i was imagining a workflow where the update steps are interleaved with belief propagation steps every so many gates, which should be relevant mostly for gates that aren't too close to the identity. (Or in other words, can we take larger time steps like this?)

What I am also wondering is how you feel about the code style. I think I deliberately used functions that are a bit larger, since I found that the many different helper functions (especially for obtaining directions and axes) make it a bit hard to see what is going on in total, while the total amount of code actually does not go down all that much. Of course I still have to add the PEPO versions, and the 3-site stuff, but I at least found this code a bit easier to read.

Finally, I was looking at this and was wondering if we can't further improve: currently we are absorbing 3 messages per PEPS tensor, then doing some stuff, and then I absorbing 3 messages, and I was wondering if we shouldn't switch that around and by default keep all messages absorbed, unabsorb just 1 on the connecting leg, and then absorb that again in the end. This should reduce the cost/allocations of that part by quite a bit, unless I am missing something?

[Yue-Zhengyuan]

by default keep all messages absorbed, unabsorb just 1 on the connecting leg, and then absorb that again in the end

This is indeed more efficient (if one only cares about the end result) 👍 Though it does not play well with the current TimeEvolver interface, which returns the state itself after each step of evolution to give users access to intermediate steps (unless we require users to remove the weights/messages by themselves).

[Yue-Zhengyuan]

I would be surprised if the diagonal parts are really dominant.

If I understand correctly, after one round of update, all BP messages will become diagonal? Same on L179 (gate on vertical bond) below.

[lkdvos]

Yes, although they are implicitly converted back to dense because of the setindex! calls here. I'd have to investigate if this is really important

[Yue-Zhengyuan]

the many different helper functions (especially for obtaining directions and axes) make it a bit hard to see what is going on in total, while the total amount of code actually does not go down all that much

You may have the feeling because there is only simple update right now. Writing all these small helper functions may be justified once we have NTU and full update as well.

The main point is whether we want to update each bond at its original position to reduce rotations and improve performance, or always first rotate the bond to a standard orientation to write less code. For NTU and full update, writing code to construct the bond environment in all orientations without rotating the state (as done by YASTN) is very prone to mistakes. So I decided to sacrifice the performance a bit and rotate the states...

[Yue-Zhengyuan]

where the update steps are interleaved with belief propagation steps every so many gates, which should be relevant mostly for gates that aren't too close to the identity

I do recall this being tested in the BP gauge fixing paper. Anyway, BP gauge fixing steps can also be added to current SU without doing everything with BPEnv.

BTW, in context of NTU, the YASTN people have shown that the bond environment there can also be improved by further attaching BP messages to the neighbourhood tensors (@sanderdemeyer is also interested in that). At some point the BP gauge fixing will be part of the NTU code as well.