Skip to content
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

XML files and UPF files have different reference states #69

Open
camelto2 opened this issue Dec 3, 2021 · 2 comments
Open

XML files and UPF files have different reference states #69

camelto2 opened this issue Dec 3, 2021 · 2 comments

Comments

@camelto2
Copy link
Contributor

camelto2 commented Dec 3, 2021

I don't think this is necessarily high priority, but it was the source of some confusion in some discussions I'm having with the RMGDFT developers who have added the capability to use our XML format for the semilocal pseudopotential evaluations.

For example, the Mg UPF file (converted to UPF v2.0) has

<PP_CHI.1 index="1" label="S " l="0" occupation="1.000000000000e0">
  </PP_CHI.1>
<PP_CHI.2 index="2" label="P " l="1" occupation="5.000000000000e-1">
  </PP_CHI.2>
<PP_CHI.3 index="3" label="D " l="2" occupation="5.000000000000e-1">

The Mg.ccECP.xml has zero occupation for the p and d channels

<vps principal-n="0" l="s" spin="-1" cutoff="3.465" occupation="2">
<vps principal-n="0" l="p" spin="-1" cutoff="3.465" occupation="0">
<vps principal-n="0" l="d" spin="-1" cutoff="3.465" occupation="0">

This is because we originally generated the quantum chemistry formats (nwchem, molpro, gamess, etc) and the qmcpack xml file using ppconvert which would perform a DFT solve for an atomic state regardless of the output format of the potential. QMCPACK for example, makes no use of the atomic orbitals or the reference state, but ppconvert would still solve for a state and store it in the xml file. So, we just chose the ground state occupation in most cases.

When we later added the UPF files, we tended to use reference states which had some fractional occupation for each angular momentum. This obviously results in a discrepancy between the atomic states in the XML and UPF files.

The reason this makes a difference is that in RMG, even though they can directly evaluate the potentials using a semilocal format, they need the atomic states in the file to use an LCAO guess from the xml format. Depending on the system, these differences in the LCAO guess could impact convergence and can lead to some confusion when comparing to the Kleinmann-Bylander evaluations uing the UPF format.

It would be much cleaner to have the XML and UPF files have the same atomic states stored, so ideally the XML files need updating. I believe most of the more recent potentials would have used the same atomic state, but for the original set of potentials we updated there may be discrepancies.

Updating the xml files to match the UPF atomic state would not impact any QMCPACK applications using those potentials since in QMC we don't use the atomic states.

@camelto2
Copy link
Contributor Author

camelto2 commented Dec 3, 2021

Also, it looks like potential files that generated the QMCPACK xml format using my modified version of opium (e.g. the softer version of Fe) the atomic orbital aren't written at all. So, I don't think RMG could use these since they need the atomic states to get a LCAO guess

I can easily add this, but at the time QMCPACK was the only code using out xml format so I didn't bother writing the orbitals to the xml

@jtkrogel
Copy link
Contributor

jtkrogel commented Dec 3, 2021

Good catch. Accelerating the convergence is important.

Another relevant issue is that if one calculates Lowdin/Mulliken charges (which we generally have an interest in doing), then the atomic states from the UPF file get used for this as a basis. These states should therefore be physically reasonable w.r.t. the atom in order for the DFT/QMC charges to have at least some degree of interpretability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants