fermi_level

[atztogo]

At PR #458, fermi_level was removed because it may not exist always. But in my calculation settings at the latest aiida-vasp, it always exists, and it is sometimes useful. If it always exists, I think it is not so harmful having it in misc. How do you think? But does anybody know In which case it doesn't exist?

Is there any simple way to include fermi_level in misc? What I tried was

    settings.parser_settings = {
        "add_misc": [
            "total_energies",
            "maximum_stress",
            "maximum_force",
            "magnetization",
            "notifications",
            "run_status",
            "run_stats",
            "version",
            "fermi_level",
        ],
    }

but in this case, I have to write all the values to be included in misc. Another try was

    settings.parser_settings = {
        "add_custom_node": {
            "type": "dict",
            "quantities": [
                "fermi_level",
            ],
            "link_name": "fermi_level",
        },
    }

This results in (report of VaspCalculation)

% verdi process report 33037
*** 33037: None
*** (empty scheduler output file)
*** (empty scheduler errors file)
*** 2 LOG MESSAGES:
+-> ERROR at 2021-11-29 10:07:48.141551+00:00
 | invalid value uuid: 09d1a40d-c189-424d-be41-4d0bcb10dc10 (unstored) specified with label fermi_level: Error validating output 'uuid: 09d1a40d-c189-424d-be41-4d0bcb10dc10 (unstored)' for port 'outputs': Unexpected ports {'fermi_level': <Dict: uuid: 09d1a40d-c189-424d-be41-4d0bcb10dc10 (unstored)>}, for a non dynamic namespace
+-> WARNING at 2021-11-29 10:07:48.144915+00:00
 | output parser returned exit code<10>: The process returned an invalid output.

[zhubonan]

I think it was because fermi_level does not present in vasprun.xml if DOS calculation is not perofrmed (it is parsed form the dos section). VASP always perform DOS calculation at the end of the calculation but if the calculation is terminated midway (e.g. wallclock issue) then fermi_level will not be present.

However, I do this we should make it avalaible if it is there. At the moment the parser will give an exit code if there are quantities that are requested but not avalaible. We should allow this functionaity in general.
As a quick fix, we can simply have the vasprun.xml return fermi_level as None if it is not present.

aiida-vasp/aiida_vasp/parsers/file_parsers/vasprun.py

Lines 731 to 735 in 76bfcd3

	@property
	def fermi_level(self):
	"""Fetch Fermi level."""
	return self._xml.get_fermi_level()

    @property
    def fermi_level(self):
        """Fetch Fermi level."""
        try:
            efermi = self._xml.get_fermi_level()
        except KeyError:
            efermi = None
        return efermi

[espenfl]

Yes, I think this was done when running for instance relaxation. Then the fermi_level is not there. According to our discussion here #532 None will be returned in the future. Then the question becomes, when the user specifies that the fermi_level should be in the misc node, if we should raise on it or not. Also goes for defaults. I think we should raise and then the caller is responsible of evaluating if that error is of concern to the workflow in question. Only the caller would be able to tell.

[atztogo]

Thanks @zhubonan and @espenfl.

VASP always perform DOS calculation at the end of the calculation but if the calculation is terminated midway (e.g. wallclock issue) then fermi_level will not be present.

I see. I didn't consider this case. Then, this issue is not limited for fermi_level. If the VASP output file (OUTCAR or vasprun.xml) is truncated, an exit code is raised. Handling error for each returned value from the particular parsers would be hard, so we can ask users to consider the absence of the requested value means the signal that something unexpected happened. But at least we can report which value was None.

[atztogo]

@espenfl

Yes, I think this was done when running for instance relaxation.

I confirmed this. Thanks. In the case I encountered, efemi exits in OUTCAR, but not in vasprun.xml.

[espenfl]

Yes, we should try to make this behaviour more well defined. Starting to return None for most quantities is one. Then we raise an error if the user requested a particular quantity (or if it is default). It would not be an error for each returned value I think. That would be possibly to extensive. Also the errors can be tailored now rather easy, so we can dress the message with more context. How to act on this depend entirely on the caller. If it is a workflow using the quantity is should fail hard, or at lest try to mitigate. If not, then maybe it can continue. But these are again workflow design issues for the particular workflows. What we can do now I think is to make sure we have enough information at hand for any user to act accordingly.

[zhubonan]

Right I see, may be we should allow passing another list at VaspCalaculation level (with some sensible defaults) of quantities that are OK to be not returned? For example, we can include maximum_stress (not computed with hybrid function, undocumented default) and fermi_level in the list, similar to what we do for parser_setting. If any of the rest of the requeted quantities is None then we given an non-zero return code.

[zhubonan]

I confirmed this. Thanks. In the case I encountered, efemi exits in OUTCAR, but not in vasprun.xml.

Hmm, the one from OUTCAR is not used as the one in the vasprun.xml with name fermi_level does not the former is its alternative. If we switch on the alternative, will it work?

[espenfl]

Right I see, may be we should allow passing another list at VaspCalaculation level (with some sensible defaults) of quantities that are OK to be not returned? For example, we can include maximum_stress (not computed with hybrid function, undocumented default) and fermi_level in the list, similar to what we do for parser_setting. If any of the rest of the requeted quantities is None then we given an non-zero return code.

Yes, maybe. Especially maybe for subsets of defaults. But if a user has specifically requested something we need to assume the user needs it and raise whatever needs to be raised. Then the caller should act on that.