VASP 5.4 compatibility?

[wladerer]

Hi everyone,

It seems like one of the BulkSet default INCAR tags is EFERMI, a feature that is only compatible with VASP 6.4. If I were to try to run the calculation, it would fail due to an unrecognized tag. I tried to edit the BulkSet.yaml file and provide my own yaml file, but it seems that maybe custodian is adding this tag by default.

Versions:

• python 3.11.7
• quacc current
• vasp 5.4

Test script:

from ase.build import bulk
from quacc.recipes.vasp.core import relax_job

# Ni cubic
atoms = bulk('Ni', cubic=True)

job = relax_job(atoms)

Error

 distrk:  each k-point on   32 cores,    1 groups
 distr:  one band on    1 cores,   32 groups
 using from now: INCAR
 vasp.5.4

 POSCAR found type information on POSCAR  Ni
 POSCAR found :  1 types and       4 ions
 Error reading item 'EFERMI' from file INCAR.
 Error code was IERR=5 ... . Found N=    0 data.

I am only learning Quacc so I feel like there might be a setting I am missing like ASE's vasp_version that I can hand off to a calculator.

Update:

So I was somewhat wrong, it was simply that quacc/calculators/vasp/params.py has a function that does a pretty diligent job of updating your incar with reasonable defaults. One of them is using the EFERMI = MIDGAP setting recommended in the vasp wiki. Unfortunately, this means it will crash 5.4 if you have this setting on. I do like the suggestions by the INCAR copilot, so I made the following edit in the get_param_swaps() function.

    if not calc.string_params["efermi"]:
        logger.info(
            "Copilot: Recommending EFERMI = MIDGAP per the VASP manual (available in VASP 6.4+)."
        )
        #calc.set(efermi="midgap")

Quick Solution for VASP 5.4 users is to turn off incar_copilot, if you do not want to edit source code and are happy with the default settings you give the vasp calculator. I hope this helps

[Andrew-S-Rosen]

Thank you for your post, @wladerer! A few things to unpack here.

First, here is how the VASP recipes work:

1. A default set of parameters are available. These are defined in the recipe definition as well as the preset, if one is specified.
2. The user can supply any custom keyword arguments to the recipe, which will always take precedent and never be overwritten. For instance, doing static_job(atoms, efermi="legacy") would always ensure efermi="legacy" is retained (although I understand that won't help in your scenario because VASP 5.4 does not have such an option).
3. By default, there is a VASP_INCAR_COPILOT setting (which can be toggled) that will check your parameters to see if any conflict with what is written in the VASP manual. If any inconsistencies are found, it will make a swap and log that information in stdout. However, it will never overwrite a variable you have explicitly set.

With this understanding in place, let's discuss what might be happening. efermi="midgap" should not be updated automatically in quacc (check the logs in stdout to be sure) as of v0.9.4 released yesterday. Custodian itself doesn't have any updates for efermi in place. It looks like you are using a current version of quacc, so this is likely not relevant, but I bring it up anyway.

By default, BulkSet.yaml does have efermi="midgap" in it since that's what the VASP manual recommends, even though it is not support for VASP 5.x. Defining a new preset and using that should help, so I'm not 100% sure what went wrong in your scenario (certainly, if you can reproduce this behavior please let me know in case it is a bug). You can also try setting

from quacc import Remove

relax_job(atoms, efermi=Remove)

This is a bit of an "advanced" feature that will ensure efermi is removed from the final list of inputs. The Remove (like any directly specified keyword argument) will never get overwritten, even if we did still have the INCAR copilot swap present. Let me know how that goes.

There is not currently a minimum VASP version setting, although it is trivial to add in if deemed necessary (in fact, there used to be one a long time ago). My philosophy for this was that soon enough, most people will not be using VASP 5.x. 😉

[Andrew-S-Rosen]

One of them is using the EFERMI = MIDGAP setting recommended in the vasp wiki. Unfortunately, this means it will crash 5.4 if you have this setting on.

That should not be present in quacc as of 0.9.4.

[wladerer]

Oh that is a wonderful feature, thank you! I am sorry to add more overhead to maintaining this project. The **kwargs feature of python has always been a weak spot for me, but now I see how you can make these functions way more flexible.

Thank you again

[Andrew-S-Rosen]

No need to apologize! I am here to help, particularly when you provide such detailed reports, which help greatly in providing an appropriate response. Don't hesitate to let me know if you run into other issues or if this particular issue remains unresolved.

As a side-note, I think you can probably even just do efermi=None if my docstrings are not lying to me. I would try that rather than the Remove logic first.

[wladerer]

yes, efermi=None worked!

[Andrew-S-Rosen]

Woo!