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).
Hi @mscheidgen. Just a reminder about this issue. Let me know if additional details are needed.
We added this to our internal issue system here. But it might take a while until we can pick it up.
Would be great if you can send the vasprun.xml file so I can add it to the testbed.
@ladinesa, sure. Attached you can find sample meta-GGA (
hle17_vasprun.xml) and hybrid (
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.
hle17_vasprun.xml.gz (1.3 MB)
hybrid_vasprun.xml.gz (1.4 MB)
We are using the libxc naming convention and for most of the hybrid functionals including HLE17, we do not have a mapping to the appropriate name.
For the other case, it is indeed what happened.
I will commit a fix to these issues tomorrow.
Re: hybrids, makes sense! Thanks.
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.
You can see an example of what I mean here: NOMAD
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.
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 exactly
HYB_GGA_XC_HSE06. HSE06 takes the following parameters:
LHFCALC = .TRUE. HFSCREEN = 0.2. With the defaults: AEXX=0.25, AGGAX=1-AEXX=0.75, AGGAC=1.0 and ALDAC=1.0.
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.