-
Notifications
You must be signed in to change notification settings - Fork 139
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
Odd permutation applied to orbitals for complex to real B-splines #4673
Comments
Investigating further, I computed overlaps between the outputted complex orbitals and the real ones. Below is a listing of the complex orbitals (index in first column) along with which real orbitals (indices in third column) they have finite overlap with. Blank lines separate different primitive cell k-points.
As can be seen, there is a large permutation applied to the orbital list (in addition to sqrt(2)/2 orbital pair mixing for complex to real). In the complex code, the gamma point orbitals appear at the very end of the list. Possibly this permutation is the root cause of the occupation (and charge imbalance) difference between the real and complex codes. Since the permutation will in general negatively impact usage of the orbital sets as a basis (as in the 1RDM), I'm labeling this as a bug, even in absence of full proof that the permutation causes the charge imbalance in #4549. |
Looked at at 5.00A real code.
complex code
So far from the builder output, I think the code picked consistent orbitals between real and complex builds. |
Uncovered while investigating #4549.
In #4549, a sudden jump in the energy is observed for bilayer graphene, which is largest in the elec-elec energy. @rcclay observed that the charge density in the problem case is asymmetric between the layers.
Here, I printed orbital values directly from QMCPACK to disk (no QMC) and integrated the per orbital charge densities to get per orbital per layer charge contributions.
Similar to @rcclay, I found one layer has more charge (74 elec on one layer, 70 on the other). The charge imbalance is observed with the complex build of QMCPACK. The real build (same inputs!) shows no such charge imbalance at the orbital level.
This suggests a possible bug in how occupations are handled in the complex code while running with real valued orbitals (gamma point).
Complex code results:
Real code results:
The text was updated successfully, but these errors were encountered: