Open romanfanta4 opened 7 months ago
As part of https://github.com/QMCPACK/pseudopotentiallibrary/issues/89 , the UPF files are going to be regenerated. We should check/retest then.
I want to add that the reference states listed in the header files being different from the ground state is not a bug per se. There were a few reasons for them to be different. For example, depending on the chosen reference state, one gets a different quality of transferability, existence of ghost states, and different convergence behavior. So due to these factors, the transition metal upf
files were usually generated with ionized states, mostly removing the outer valence s-orbitals. As these are single-projector ECPs (KB form), it nominally should not be an issue when you run PW codes. For example, if you run Cu atom in a large box, you should see the correct electronic ground state.
However, there is probably room for improvement in choosing the reference states, as you correctly pointed out the lack of 4s states. There is also a related discussion in #69. For example, when calculating Lowdin charges, the reference states are used as the basis, and thus, there is a non-zero charge spilling. The reference states should, therefore, be reasonable enough to result in small charge spilling. I am guessing including a small fractional occupation for 4s should improve the charges/moments there. At some point, we need to regenerate all upf
(#89, #104) and xml
(#69) files.
Opium doesn't ever show the second of any l channel. It only does the first in my experience. Adding to what Gani mentioned, the place to check for the expected performance of the upfs on various configurations is going to be at the end of the .rpt files. A number of configurations are run and the discrepancy vs the AE is shown in eV. In pretty much every case the nominal ground state is tested which would have the configuration mentioned by Roman.
Hello, I've noticed a bug/discrepancy in the pseudopotential headers for copper (Cu-soft vs Cu original) and silver.
Could you help me understand the reasoning behind these specific occupancy values, or is it just a bug? When running the Quantum Espresso calculations with Cu, the number of electrons, is correctly set, but correct labeling of occupations is crucial for DFT+U.
Cu.ccECP-soft.upf:
Cu.ccECP.upf_deprecated:
Same issue is for Ag.ccECP.AREP.upf: