I want to relitigate #906. The problem as I now understand it: pseudos are constructed on a log grid. To transfer to UPF, they are (sometimes) interpolated. This is a problem for the potential, because the Coulomb correction assumes that the potential goes exactly like Z/r and erf-corrects it. Interpolation errors compound with the r^2 and give real errors. Caveats: Claude says SSSP log grid still have this problem, so maybe it comes from somewhere else?
Issues with the current code
- this rcut is a hack
- it's used to stop integration for all quantities, even valence densities, which is plain wrong - claude tells me it gets the valence charge wrong by 5% on Cs
- gives significantly different results if we load a pseudo through a family or directly
Issue 2 is easily fixable. Issues 1 and 3 less so. If there's a rhocore in the pseudo, we can detect where that goes to almost zero and truncate vloc-Z/r after this. Otherwise we have to get the radius from somewhere. We can try to detect where vloc goes bad by monitoring vloc-Z/r and seeing where that starts to go up, but that's brittle. We can hardcode it (apparently that's what QE does, at 10). I think what I'd like to do is: if nlcc, get it from where core charge is <1e-10. If not but given by the pseudo family, take it. Otherwise, pick 6 (Claude looked at the numerical artifacts and found some of them starting at 6, so QE's 10 is too much). If we want something more principled, we could try to build a table of core radii, a bit like we do with atom_decay_length. @azadoks thoughts?
I want to relitigate #906. The problem as I now understand it: pseudos are constructed on a log grid. To transfer to UPF, they are (sometimes) interpolated. This is a problem for the potential, because the Coulomb correction assumes that the potential goes exactly like Z/r and erf-corrects it. Interpolation errors compound with the r^2 and give real errors. Caveats: Claude says SSSP log grid still have this problem, so maybe it comes from somewhere else?
Issues with the current code
Issue 2 is easily fixable. Issues 1 and 3 less so. If there's a rhocore in the pseudo, we can detect where that goes to almost zero and truncate vloc-Z/r after this. Otherwise we have to get the radius from somewhere. We can try to detect where vloc goes bad by monitoring vloc-Z/r and seeing where that starts to go up, but that's brittle. We can hardcode it (apparently that's what QE does, at 10). I think what I'd like to do is: if nlcc, get it from where core charge is <1e-10. If not but given by the pseudo family, take it. Otherwise, pick 6 (Claude looked at the numerical artifacts and found some of them starting at 6, so QE's 10 is too much). If we want something more principled, we could try to build a table of core radii, a bit like we do with atom_decay_length. @azadoks thoughts?