A quick question about how Compatibility is handled… in Pymatgen there are classes such as MaterialsProjectCompatability2020 that ensure computed entries have necessary parameters and meet certain MP standards. One of these is to check that the potcar is the MP-recommended one. How is compatibility handled if a non-VASP calc is performed where params and calculation standards are different? For example, Abinit calculations were performed for phonon database, and presumably those had to be processed with some kind of compatibility (or maybe they weren’t…?)
The compatibility scheme exists to compare energies of two different calculations for the purposes of constructing phase diagrams, specifically to be able to mix GGA and GGA+U calculations, and to correct for systematic errors introduced by DFT.
The “pseudo-potential correction” is actually a fake correction – it is only present to make sure that the correct pseudo-potentials are used, but it never changes the energy of the calculation.
Since Materials Project is predominantly VASP, the entry classes have also only ever been used with VASP. The entry format is fairly freeform and loose, so it could be used with other codes (e.g. make sure to set a “Hubbard” key correctly in the data dictionary), but the actual values of the compatibility scheme would have to be completely re-fitted.
The phonon calculations you mention were indeed calculated with ABINIT – but since the phonon calculations “speak for themselves” they never needed to be corrected, since they do not need to be directly compared to each other.
Amanda Wang and @rkingsbury have developed MaterialsProjectCompatibility2020 so maybe they have additional input.
This all being said, if there is sufficient community interest and availability of resources, a generalized correction scheme across codes could be very interesting. We’ve contemplated PD construction in formation energy space as one means of mixing calculations from any code.
Yes, agreed. One of the current weaknesses of the Entry class is that it allows a lot of free-form data to be included, formalizing this (and thus making it accessible for other codes as well) would be very interesting.
Yeah @shyamd that’s exactly what I am doing manually at the moment. Manually constructing PDs in formation energy space using two codes’ (CP2K and VASP) energies together. So that’s why I started wondering a little bit about how compatibility works.
The compatibility is all about ensuring calculations can be used together and then applying corrections.
You’re sort of in no-man’s land by mixing VASP and CP2K in general. Ideally, someone would go about identifying a set of calculation settings across codes that demonstrated good mixability and that’s what would get used.
I believe all the materials used to fit the correction scheme are indicated. It would be possible for someone to just run those same calculations to rebuild the correction scheme for CP2K and once those are all applied the formation energies should be mixable.
1 Like
I believe all the materials used to fit the correction scheme are indicated. It would be possible for someone to just run those same calculations to rebuild the correction scheme for CP2K and once those are all applied the formation energies should be mixable.
Yes, this is the case – you can just run the set of crystal structures specified, initialize + re-fit. It would be a few hundred calculations. There’s a .json in pymatgen.
I only know of the GGA/GGA+U and the gas correction, but these are agnostic to implementation under light assumption I believe. If you assume that two codes produce the same formation energies, then you can do:
Definition: E_{form.}(x) = E(x) - \sum_{el}\mu_{el} with \forall el \in compound
Assume: E^{VASP.}_{form}(x) \approx E^{CP2K}_{form}(x) \to E^{VASP.}(x) \approx E^{CP2K} + \sum_{el} (\mu_{el}^{VASP} - \mu_{el}^{CP2K})
Which allows you to apply, say, O2 correction scheme that already exists, because you have shifted the reference stat from CP2K to VASP.
Assuming formation energies are the same essentially amounts to saying “assuming precision is well converged, viz. k-points, basis sets, matrix filtering, etc., the only error which remains between to codes using the same functional should be the pseudo-potential error”. Pseudo-potential do obviously produce different results, but so long as that error is small, the approximate equality of formation energies should hold.
Now some things don’t transfer over so easily. For example, Hubbard U values need to be re-fitted since those are implementation dependent.
You could do what you said and re-fit the whole correction scheme instead, but this is still an important fact because it allows conversion between energy scales. Otherwise, you cannot use VASP and CP2K energies together because they have totally different energy scales.
You make a good point @Nicholas_Winner that if we assume the correction values reflect errors in the DFT itself and not in the pseudopotential, and that the calc is well converged, we should in principle be able to apply the same fitted corrections when we calculate a formation energy from another code. We obviously have not tried this; it would be interesting to see how well it works.
We do think creating PhaseDiagram in formation energy space is the best path forward for this general problem of mixing energies from different functionals/codes, and I’m working on some mixing code that does that. Although the primary intended use case was to mix energies from different functionals; it could work just as well for energies from different codes.