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
Continuation Charge Sector Projection #363 #398
base: main
Are you sure you want to change the base?
Conversation
…MPS into MPS class In the classmethod from_infiniteT_canonical of PurificationMPS the first step corresponds to finding a tree of possible charges at each site which corresponds to the desired charge sector. This logic is moved into the MPS class as it will be used to project a product state onto a desired charge sector. The classmethod from_infiniteT_canonical is adapted.
… MPS This is similar to the method from_infiniteT_canonical of the PurificationMPS class. In the canonical ensemble each local basis state has the same probability in a charge sector. For the new classmethod project_onto_charge_sector it is possible to pass a list of coefficients for each local basis state for each site in the desired charge sector. This effectively projects a product state onto a desired charge sector.
and remove unnecessary sorting in `get_charge_tree_for_given_charge_sector`
Simplify initialization of sites and add comments to the test. Furthermore include a test for conservation of ``'N'`` for `FermionSite`
I think Ludwig and Philipp are already addressing this, but just as a reminder here: PurificationMPS.from_infiniteT_canonical doesn't work with two independent charges, as also pointed out in this forum thread |
This fixes the method `project_onto_charge_sector` in mps.py. A charge tree can now be generated for more than 1 type of charge. Update test_cs_projection.py accordingly and include a test for `PurificationMPS.from_infiniteT_canonical`. Add some comments to better understand how the "tree" is constructed.
Add cs-projection to changelog
I just updated the method |
This is a continuation of #363 (due to renaming of the repo/branch)
Closes #363