-
Notifications
You must be signed in to change notification settings - Fork 26
Add C4v CTMRG #321
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
Add C4v CTMRG #321
Conversation
|
Your PR no longer requires formatting changes. Thank you for your contribution! |
|
This PR already involves lots of things. For QR CTMRG, besides getting projectors from QR instead of SVD, the way to enlarge corners is also different. Maybe we focus on the |
Completely agree, I anyway assumed this would go into a separate PR. Also I apologize for making this PR so big, I found it somewhat hard to split up the changes needed to make the whole apparatus compatible with C4v CTMRG. |
One approach is to make |
Codecov Report❌ Patch coverage is
... and 2 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Co-authored-by: Yue Zhengyuan <yuezy1997@icloud.com>
Co-authored-by: Lukas Devos <ldevos98@gmail.com>
|
This is good to go for me now, let me know what you think! |
|
I'll unlink issue #258 until we also implement the QR-CTMRG. |
| function c4v_renormalize(network, env, projector) | ||
| new_edge = renormalize_north_edge(env.edges[1], projector, projector', network[1, 1]) | ||
| return new_edge / norm(new_edge) | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to further project_hermitian the updated edge with respect to the two environment indices to eliminate numerical errors?
See also the QR-CTM code which does this step.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW, I would add a leading underscore (_project_hermitian) to avoid conflict with MAK. But it's just my opinion...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition, do we have tests with fermions to see if project_hermitian for edges is correctly defined? I'm not quite confident on the usage of flip there unless it's proven correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, thanks! Probably doesn't make too much of a difference but it should stabilize the method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition, do we have tests with fermions to see if project_hermitian for edges is correctly defined? I'm not quite confident on the usage of flip there unless it's proven correct.
Good point, I'm also not sure if flip and _dag work for fermions right away. Would you have an idea for a quick test? (I wouldn't want to add too much more to this PR.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave the fermions for a follow up, it will be easier to review what is going on that way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test idea is simple: create a random fermionic state with C4v, converge the environment with both C4v and asymmetric CTMRG, and evaluate the expectation value of a random operator, which should be the same for both cases. But frankly, I'm not even sure if the current symmetrize! plays nicely with permutation signs from FermionParity.
lkdvos
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some small final comments, but otherwise good to go!
| function c4v_renormalize(network, env, projector) | ||
| new_edge = renormalize_north_edge(env.edges[1], projector, projector', network[1, 1]) | ||
| return new_edge / norm(new_edge) | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's leave the fermions for a follow up, it will be easier to review what is going on that way.
Co-authored-by: Lukas Devos <ldevos98@gmail.com>
|
Should be mergeable now! |
In this PR we will finally add a dedicated C4v CTMRG algorithm. I started with the standard version using
eighprojectors but we can easily also implement a QR version by making aC4vQRProjectoralgorithm and the correspondingc4v_projectormethod. (@Yue-Zhengyuan said he would be up for doing this :-)) This C4v routine is completely differentiable using naive AD,:diffgaugeand:fixedmode.Note that I needed to generalize the
gauge_fixmethod forCTMRGEnvs to not have separate methods for all the C4v stuff. Same thing is true for environment initialization, where it would be nice to have aninitialize_environmentmethod where one can dispatch on an algorithm. Here we'll have to wait until we merge #264.Let me also say that it would eventually be nicer to have a dedicated
C4vCTMRGEnvsince this would make things cleaner. However, this would entail a larger rewrite of quite a few things, so I propose that I postpone this rewriting and cleaning up process until I have more resources for that again. (In general I feel like we should clean up and refactor some stuff again since the codebase has been growing quite a bit.) Anyways, for now it would be nice to have a working C4v CTMRG that people can use.This is still very much under construction but I'll finish up things and adjust the test suite tomorrow.