Specifying both GGA and METAGGA tags in VASP

[esoteric-ephemera]

Introduce custodian handler to ensure that both GGA and METAGGA are not included in INCAR on VASP runs. See: https://github.com/materialsproject/atomate2/issues/453 for more detailed information and examples

Specifying both GGA and METAGGA can lead to order of magnitude changes in the total energies

[shyuep]

Shouldn't this be caught in the input sets themselves?

[esoteric-ephemera]

It needs to be caught prior to running VASP / writing the input set. When generating the input set, it should take the method of higher precedence (METAGGA over GGA if both are specified) - any thoughts @janosh?

Are you suggesting the PMG input set generators are a better place for this fix @shyuep?

[shyuep]

Yes. My general philosophy is:

1. Predictable errors, e.g., conflict between known parameters like METAGGA and GGA, should be correctly set/caught in input sets.
2. Unpredictable errors, e.g., runtime issues of symmetry errors, convergence errors, etc. should be caught in Custodian.

Custodian is meant to be a last line of defence.

One way we can do this, is to add a pre-validation (a collorary to the existing post-validators) to Custodian to check for nonsense input like these. Ideally though, this really needs to be settled in input set generation.

[janosh]

I think this should be handled in both pymatgen input sets and in custodian.

I don't think there's any scenario where having both GGA and meta-GGA incar tags is ever intended behavior.

[shyuep]

Why don't we do a pre-validator then? I don't think we want the run to actually proceed before checking for these things.

[rkingsbury]

I agree with @shyuep , some pre-validation in InputSet makes sense. In fact, we envisioned a validate method as part of the new InputSet interface designed to catch predictable errors.

[shyuep]

I think what @janosh said was to do it both in the InputSet and in Custodian. For sure the input set should do it. I am less convinced of doing it in Custodian, but I think a pre-validator in Custodian would be the best way to handle such issues.

[matthewkuner]

I could see a world where someone uses non-MP input sets while also using Custodian, so perhaps that is an argument for including a check in Custodian as well?

[matthewkuner]

Update from offline discussions with @esoteric-ephemera: For calculations with METAGGA = R2SCAN set in the incar...

• Setting GGA = -- in the INCAR still results in the same energy as not including it at all (sanity check passed)
• Setting GGA = PE in the INCAR results in the same energy as not including it at all
• But, setting GGA = PS in the INCAR results in an energy discrepancy of an order of magnitude (as @esoteric-ephemera said in the original post)

So how you set GGA dictates whether this bug shows up or not, as opposed to setting this tag always causing this issue.

[shyuep]

Erm, but GGA=PS means revised PBE for solids. It is not the same as GGA=PE (standard PBE). It is not completely surprising it leads to different energies?

[esoteric-ephemera]

The thinking was that if both GGA and meta-GGA are set, the actual final energy and forces should be computed with the meta-GGA only, since this is the order in which the functions are called in VASP (the GGA KS potential then meta-GGA KS potential, which overwrites it). So in that case, using GGA = would give you only the meta-GGA energies, forces, etc.

But it seems like the GGA actually changes (maybe) the pseudocore energies, but not the valence electron energies nor forces. I'm trying to confirm this with VASP