Understanding the Need for Separate LDA and PBE Pseudopotentials Given the GGA Tag's Flexibility.

[hszhao.cn@gmail.com]

Greetings VASP Community,

As I delve deeper into the capabilities of VASP, particularly the flexibility afforded by the GGA tag in encompassing both LDA and GGA functionals, a question emerges regarding the pseudopotential libraries provided: potpaw_LDA.64.tgz and potpaw_PBE.64.tgz. Given that the GGA tag allows for the application of both LDA and GGA functionals, it raises the inquiry of why both LDA and PBE pseudopotential libraries are necessary, especially if potpaw_PBE.64.tgz could potentially cover the functionalities of potpaw_LDA.64.tgz.

Could the community offer insight into the advantages or specific scenarios where the distinct characteristics of LDA pseudopotentials are not only preferred but necessary, despite the encompassing nature of the GGA tag? This query stems from an interest in understanding the underlying considerations for pseudopotential selection, particularly in cases where one might assume that PBE pseudopotentials could suffice for a wide array of applications.

Thank you for shedding light on this aspect of computational setup in VASP.

Regards,
Zhao

[martin.schlipf]

The reason for having two distinct PAW libraries may be partially historic and partially for validation: Since, we can reconstruct the all-electron orbitals from the pseudo-orbitals both approaches should lead to the same result. You can verify this for yourself by calculating a system with LDA set via the POTCAR or the GGA tag. One can use this test when implementing new features that rely on the xc potential.
Historically, VASP used to support other types of pseudopotential where the choice between LDA and PBE did make a difference, so in the earliest versions of the PAW it may not have been obvious whether the reconstruction is sufficient to yield the same results for all properties.

[hszhao.cn@gmail.com]

Since, we can reconstruct the all-electron orbitals from the pseudo-orbitals both approaches should lead to the same result.

Do you mean that: Within the PAW framework, "all-electron orbitals" can be reconstructed from the pseudo wave functions, allowing VASP to simulate results that are closely aligned with all-electron calculations, such as the method implemented in WIEN2k?

[martin.schlipf]

Yes, VASP should reproduce results of Wien2k within the frozen-core approximation. You can even go one step further and recompute the eigenvalues of the core states (ICORELEVEL) but this is typically not done.

[hszhao.cn@gmail.com]

You can even go one step further and recompute the eigenvalues of the core states (ICORELEVEL) but this is typically not done.

After roughly reading the document description of ICORELEVEL, it seems that the reasons for not doing further calculations as described above are as follows.

Recalculating the core energies using ICORELEVEL, especially setting it to 1 or 2, is typically not done for standard electronic structure calculations because these settings involve additional computational steps and complexities. Specifically:

• ICORELEVEL=1 involves recalculating the Kohn-Sham eigenvalues of the core states after a self-consistent calculation of the valence charge density. While this does not add significant computational cost, it provides information (core-level shifts) that is not always necessary for general electronic structure calculations.

• ICORELEVEL=2 is even more complex as it involves a fully self-consistent calculation with a core hole and an additional electron in the valence/conduction bands, which significantly increases computational demands. This level is particularly used for specific purposes, such as the calculation of X-ray absorption spectra, where detailed core-level information is critical.

For most standard calculations, the detailed information about core-level energies that these settings provide is not required. The default setting (ICORELEVEL=0) assumes that the core states do not change significantly during the calculation and thus avoids the additional computational effort. This makes it a more practical choice for routine electronic structure calculations, which is why recalculating the core energies is typically not done.

[martin.schlipf]

That is a good summary of the reasons for not computing the core levels by default and what the different ICORELEVEL choices do.