Add 3-site simple update (aka 3-site cluster update)#171
Add 3-site simple update (aka 3-site cluster update)#171pbrehmer merged 69 commits intoQuantumKitHub:masterfrom
Conversation
Codecov ReportAttention: Patch coverage is
... and 2 files with indirect coverage changes 🚀 New features to boost your workflow:
|
|
I further added a test to compare the SU and 3-site SU energy for the Hubbard model without next-nearest neighbor terms (they should be close). I think the code is now ready for fermions. |
lkdvos
left a comment
There was a problem hiding this comment.
I left some general comments throughout, keep in mind that I do not have much experience with the algorithm itself so I definitely might be missing some things or getting things wrong.
As always though, this is an impressive amount of work, and a great addition.
Co-authored-by: Lukas Devos <ldevos98@gmail.com>
|
AD optimization seems to work but it has some hickups at some point due to linesearching. I will try to improve that tomorrow. I also extended the commentary in the J1-J2 example a bit to make it similar style-wise to other examples. |
|
I decided to just restrict the |
|
@pbrehmer I'm glad to see that with SU initialization the AD energy is lower than YASTN result, so maybe a good initialization does help. How does the energy compare with the AD optimization with just 1x1 unit cell starting from random initialization? |
|
I was also happy to see that! Actually, on a 1x1 unit cell from random initialization, I'm having a lot of trouble to optimize the PEPS. There, I'm encountering degenerate singular values sometimes and CTMRG sometimes struggles to converge during optimization such that the linesearch fails. I also tried Lander's backtracking linesearch algorithm and also there I'm having problems. So my feeling is that the SU-evolved PEPS is actually quite a nice starting point for the AD optimization. I'll try to optimize that fully (up to higher accuracy) but I suspect that the environment dimension might be a little low for that - for small chi, PEPS optimization runs tend to get stuck at some point. |
|
Looking at YASTN data, the first line is So he is already using In the calculation he also imposes the geometric |
|
Indeed! I'm not yet sure if |
lkdvos
left a comment
There was a problem hiding this comment.
Left some small comments, but in general this looks almost good to go for me!
|
|
||
| Let's start by initializing an `InfiniteWeightPEPS` for which we set the required | ||
| parameters as well as physical and virtual vector spaces. Since the $J_1$-$J_2$ model has | ||
| *next*-neighbor interactions, the simple update algorithm requires a $2 \times 2$ unit cell: |
There was a problem hiding this comment.
| *next*-neighbor interactions, the simple update algorithm requires a $2 \times 2$ unit cell: | |
| *next*-nearest-neighbor interactions, the simple update algorithm requires a $2 \times 2$ unit cell: |
There was a problem hiding this comment.
Also, I'm slightly confused by this explanation: for me this sounds like next-nearest neighbor hamiltonians have a 2x2 unitcell ground state.
In principle the Hamiltonian still has a translation symmetry for a single site, so I don't think it follows automatically that you would need a
From what I understand, this is mostly an algorithmic restriction, and is a result of using simple update, so maybe we can slightly reword this to make that more obvious?
There was a problem hiding this comment.
Indeed it's an algorithm limitation. I'll make this point more clear.
| H = real( ## convert Hamiltonian `LocalOperator` to real floats | ||
| j1_j2_model(ComplexF64, symm, InfiniteSquare(Nr, Nc); J1, J2, sublattice=false), | ||
| ) |
There was a problem hiding this comment.
| H = real( ## convert Hamiltonian `LocalOperator` to real floats | |
| j1_j2_model(ComplexF64, symm, InfiniteSquare(Nr, Nc); J1, J2, sublattice=false), | |
| ) | |
| H = j1_j2_model(Float64, symm, InfiniteSquare(Nr, Nc); J1, J2, sublattice=false) |
I know this used to fail since we tried to construct Sy, was this not fixed in the meantime?
There was a problem hiding this comment.
No, I still cannot directly set T = Float64 because of S_y in MPSKitModels v0.4.2.
| Compute `exp(-dt * H)` from Hamiltonian `H`. | ||
| Each term in `H` must be a single `TensorMap`. |
There was a problem hiding this comment.
This is a bit misleading, given that this is not actually the full exponential of the hamiltonian, but rather a weird intermediate struct we use that represents sum(exp(-h * dt) for h in H) but is not used that way. (in particular, exp(sum) would be prod(exp), not sum(exp)). I don't have any issues with reusing LocalOperator that way, I would just reword the docstring.
| Check if a Hamiltonian contains only nearest neighbor terms | ||
| """ | ||
| function is_nnham(H::LocalOperator) |
There was a problem hiding this comment.
| Check if a Hamiltonian contains only nearest neighbor terms | |
| """ | |
| function is_nnham(H::LocalOperator) | |
| is_nearest_neighbour(H) | |
| Check if an operator contains only nearest neighbor terms | |
| """ | |
| function is_nearest_neighbour(H::LocalOperator) |
In general I think using longer names might be easier to read here, but I don't feel that strongly about it.
Adding the signature in the docstring is a good idea though
There was a problem hiding this comment.
Are we following the British spelling in the repo? (neighbour instead of neighbor) But I also see that center instead of centre is used...
There was a problem hiding this comment.
I think British and American spelling are mixed throughout the repo, so at this point you can use what you prefer. (Perhaps we can unify at some point but I dont think that's a super high-priority issue right now.)
There was a problem hiding this comment.
Then I just follow whatever is already in the repo.
|
@pbrehmer I tried to regenerate the J1-J2 SU example by deleting the entry in |
|
Alright this seems to be good to go now! Regarding the example cache: I think that the caching is somehow broken when running the examples from a forked repository. This might be because |
This PR adds the 3-site simple update (aka 3-site cluster update; see discussion in Issue #164), which can handle Hamiltonians containing up to next nearest neighbor terms (e.g. the J1-J2 model).
LocalOperatorformat to a bunch of 3-site MPOs acting on the clusters. Relevant functions are added insrc/algorithms/time_evolution/evoltools.jl.src/algorithms/time_evolution/simpleupdate3site.jl. It is tested in the new test filetest/timeevol/cluster_projectors.jl.examples/heisenberg_evol/j1j2.jl. We may also consider using the 3-site SU to provide initialization in the J1-J2 AD test. But note that the 3-site SU also requires a minimal unit cell size (2, 2) (in addition, bipartite structure is now not allowed), while the AD test currently uses 1-site unit cell with C4v symmetry.This is kind of a large unseparated PR. Suggestions are welcome. I'm still testing fermion models, so the code is not finalized yet.