You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR introduces the most naive algorithm to truncate the virtual space of the product of two layers of InfinitePEPOs. It is a polished version of @sanderdemeyer's work in ClusterExpansions.jl. At least it can serve as initialization for other advanced approximation methods.
The algorithm minimizes the local cost function at each virtual bond, which is the norm of
The projectors are found following steps described in Appendix A, 1905.02351 (Boundary Tensor Renormalization Group). To handle fermions, the virtual arrows are first flipped to leftwards/downwards direction with standardize_virtual_spaces.
Similar to @pbrehmer's PR #257, the function doing the truncation overloads MPSKit.approximate, and dispatches on the algorithm struct LocalApprox <: ApproximateAlgorithm.
An immediate generalization is approximate the product of an InfinitePEPO and an InfinitePEPS, but currently I don't have concrete test cases.
What you could do in the PEPS-PEPO case is to construct the PEPO as $$ exp(-d\tau H) $$, and see whether many applications of this PEPO on a random initial PEPS make it converge to the ground state. That is what I have as one of the tests in my ClusterExpansions code, which you can find here. This PEPO could be made using the Trotter decomposition, or via Simple Update, like you did in the previous tests. This should also allow for a fermionic test case.
@sanderdemeyer I don't know if you knew it before, but recently someone mentioned to me that we can optimize the HOTRG projectors (in your terminology, the "oblique projectors" in "no-environment truncation") with automatic differentiation, which is equivalent to second RG (see this paper). If you haven't tried it before, maybe I can help test this idea (also as an exercise to learn AD for me), which is also a great extension to this PR to actually make it appealing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR introduces the most naive algorithm to truncate the virtual space of the product of two layers of InfinitePEPOs. It is a polished version of @sanderdemeyer's work in ClusterExpansions.jl. At least it can serve as initialization for other advanced approximation methods.
The algorithm minimizes the local cost function at each virtual bond, which is the norm of
The projectors are found following steps described in Appendix A, 1905.02351 (Boundary Tensor Renormalization Group). To handle fermions, the virtual arrows are first flipped to leftwards/downwards direction with
standardize_virtual_spaces.Similar to @pbrehmer's PR #257, the function doing the truncation overloads
MPSKit.approximate, and dispatches on the algorithm structLocalApprox <: ApproximateAlgorithm.An immediate generalization is approximate the product of an InfinitePEPO and an InfinitePEPS, but currently I don't have concrete test cases.