When uploading a vasprun.xml file to NOMAD with a hybrid or meta-GGA functional, it still says the functional family is (incorrectly) GGA. The expected behavior is that when LHFCALC = .TRUE. is present, the family is a hybrid. Similarly, if METAGGA is not none, then it’s a meta-GGA (or meta-hybrid GGA if LHFCALC = .TRUE. is also present). Additionally, the xc functional name is not parsed correctly for such functionals. As an example, in the case of setting METAGGA to a particular functional (e.g. METAGGA = HLE17), the GGA flag is set to -- in the vasprun.xml, but NOMAD still returns PBE for exchange and correlation.
If you’re familiar with ASE, they have a nice dictionary that converts VASP inputs to functionals, which you may find helpful (as a supplement to the VASP manual).
@ladinesa, sure. Attached you can find sample meta-GGA (hle17_vasprun.xml) and hybrid (hybrid_vasprun.xml) files.
For the meta-GGA, the key thing to look for is the METAGGA flag, which has a string if it’s set. In this case, METAGGA = HLE17 and so it’s the HLE17 meta-GGA.
For the hybrid, what happened behind the scenes seems to be that the parser saw GGA = PBE and said “hey, this is PBE.” But while part of the functional is based on PBE, it’s actually a hybrid, not a GGA. The key thing to check here is if LHFCALC = T in the vasprun, which indicates it’s a hybrid. With this specific combination of PBE + 25% HF exchange, it’s the HSE06 functional as defined in the VASP manual.
Re: HLE17, just to clarify, that’s a meta-GGA and not a hybrid, but I get what you mean. The libxc ID is 288 for HLE17, but I understand there’s no mapping set up yet.
If I might make a recommendation, the vasprun.xml for meta-GGA jobs (including my HLE17 example) do not have GGA = PE (i.e. PBE) in the vasprun.xml yet this is what NOMAD is showing. An easy fix until the mapping is set up might be to simply see if METAGGA is present and is a string other than ---, and if it is, setting the functional family to meta-GGA rather than GGA. The XC functional could be left as unavailable rather than PBE until such a mapping is established.
Thanks for the input @arosen. I deployed @ladinesa subsequent fix and reprocessed the upload with that example of yours. It now shows MGGA_XC_HLE17. Let us know if this is correct and you need more of your data reprocessed.
Hi @mscheidgen. Thank you! It looks correct in that example.
All the entries in this dataset (NOMAD) have the same meta-GGA functional and should be updated to show MGGA_XC_HLE17. I see that some of them are updated, although not all.
Separately (in case it helps), all the ones here (NOMAD and NOMAD) are hybrid functionals incorrectly marked as GGA. The former is HSE06 (libxc ID 428). The latter is a modified version of HSE06 so doesn’t have a libxc reference, but it’s still in the hybrid class (as can be seen with the LHFCALC = True flag).
Yesterday, I reprocessed all your data @arosen . After a quick look, the entries now seemed to be set to HYB_GGA_XC_HSE06 and MGGA_XC_HLE17 with hybrid and meta-GGA as functional “family”.
@mscheidgen, thanks! It looks a lot better now! I can confirm the meta-GGAs are all correct and so are the HSE06’s.
Minor suggestion:
While this is entirely a matter of opinion (which I will leave up to you and the team), in the dataset here – strictly speaking – the functional is not exactlyHYB_GGA_XC_HSE06. HSE06 takes the following parameters:
In my case, I have set AEXX = 0.1, which is no longer the default. As a result, this is a custom hybrid functional based on HSE06 but not the same recipe as HSE06. Just a head’s up.
You may want to consider adding in these additional parameters as a check when parsing the functional. I’m just imagining some hypothetical downstream use-case where someone tries to do machine learning on HSE06 data on NOMAD, for which something like this could cause a quite subtle problem.