-
Notifications
You must be signed in to change notification settings - Fork 3
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
Update code to orbital resolved RDMs #5
Merged
Merged
Conversation
This file contains 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
The idea is to generalize the subtracing routine to allow the user to select in total freedom which orbitals to keep in the reduced system. This leads to two main challenges: - trace away orbitals that are sandwiched within the ones we want to keep, so care is needed to correctly assign the Fermionic sign > thanks @CarlosMejZ for the nice suggestions on the matter - define a user API to allow selecting the desired orbitals to keep in a comfortable ---but generic enough--- way. > this we are failing so far, as it is not flexible enough. So I will proceed to improve the API and hopefully recover both the missing flexibility and the back-compatibility as an overloading of the old implementation. Co-authored-by: Adriano Amaricci <[email protected]>
New API defined: getter and printer routines for density matrices now take in a logical mask, of size(Nlat,Norb), defining which orbitals to keep as T and which to trace over as F. Work in progress: sugar coated routine to let the user build the mask with the most ergonomic call, as requested by AA. Something like get_orbital_mask(site1=[1],site2=[2]…) > This would look very friendly to use in the drivers and nasty has hell in its implementation. At least we keep the wildfires in just one place, keeping a clean balance of API and implementation for the ed_get_rdm and ed_print_dm procedures. > For now is all silenced, I will finish this asap. The present compiles successfully the unchanged square lattice driver, so back-compatibility should have been preserved via overloading of the old procedures (tracing of a given number of sites, no choice on which ones and always keeping all orbitals). I will proceed to test if it also runs correctly, before updating the driver to the new API.
• Fixed the orbital stride (ops), while defining the bitwise indices of the reduced subsystem • Fixed the the call to bdecomp (states must go from 0 to 2^N-1) • Fixed the file suffix for the IO procedure ———————————————————————————————————————————————————————————————————————— A minimal test has been successful: - 2x2 plaquette (2d Hubbard, square lattice), with 2 replicas - random unconverged bath hamiltonian (and we do just one loop) – We trace down to a single site with the old routine - We trace each individual site (i=1,2,3,4) with the new routine > no diff between old and new routine for the same site (i=1) > maximum numerical difference between the old rdm (i=1) and all the new single site rdm (i=1,2,3,4) is of less than 0.12%. >> Leeet's go! ———————————————————————————————————————————————————————————————————————— [TODO] A. Perform a similar test for the 2-site RDMs (we want all 4 NN-bond RDM to be ~equal and similarly for the 2 NNN-diagonals). We can also check, on converged data points, that the NNN mutual infos match the ASCI data. B. Start testing with proper multi-orbital models, but everything should trivially generalize at this point.
Run a single loop on top of a converged point, within the large U Mott phase of the 2x2 plaquette solution of the 2d Hubbard model (square). We compare the RDMs by looking at the eigenvalues. • The two diagonals, i.e. the NNN subsystems, give eigenvalues equal up to 1d-3 (remember that sum(eigvals)=1) • The parallel NN subsystems (the two parallel to x or the two parallel to y) give equal eigenvalues up to 1d-5 • The orthogonal NN subsystems (one parallel to x and one to y) give the least similar RDMs, with eigenvalues equal only up to 6d-2. Overall it appears as the 2x2 full cluster RDM might have some numerical anisotropy, on a noticeable level, albeit not necessarily dramatic. Note that if the selected sector does not contain the groundstate (as we did for the first quick comparisons) the effect can be much more evident, as indeed is expected for excited states. More testing underway… ———————————————————————————————————————————————————————————————————————— PS. Fixed a silly error on the filename handling for the RDMs (missing trim() call on the suffix)
Of course I left an unsafe allocation of the orbital mask within the DMFT loop, so that at the second iteration the driver crashed. Here a quick fix, from ulysses. BTW, the single-site crosscheck with the semi-analytic formula appears a little bit weaker, loop by loop, out of half-filling. Probably nothing to be concerned about (still under the 1E-12 threshold...), but I'll keep an eye on it.
Removed spurious xmu terms in the calculation of - the bath hamiltonian - the weiss field - the gradient of the weiss field Which probably are vestigia of an old implementation, where the bath had no on-site energies. This fixes a simple single site test against LIB_DMFT_ED with small finite U and small negative xmu in the 2d HM.
Quickly tested on a random point, with 1 replica. Should work. Co-Authored-By: Francesca Paoletti <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
These updates have been battle tested for half a year now, so it's time to merge them into the main trunk.