VASP workchain

Required inputs

The VaspWorkChain requires a number of inputs, these comprise the minimum set of information to run a VASP calculation from AiiDA.

  • code: an AiiDA instance, describes the VASP executable and holds a reference to the Computer instance on which it lives.

  • structure: an AiiDA or instance, describes the structure on which VASP is to be run.

  • kpoints: an AiiDA instance, describing the kpoints mesh or path.

  • potential_family: an AiiDA instance, the name given to a set of uploaded POTCAR files.

  • potential_mapping: an AiiDA instance, containing an entry for at least every kind name in the structure input with the full name of the POTCAR from the potential_family. Example: {'In1': 'In_d', 'In2': 'In_h'}.

  • parameters: an AiiDA instance. Please consult the documentation on how parameters are handled (:ref parameters) for details, particularly the section pertaining to the VaspWorkChain.

  • options, an AiiDA instance, containing at least the keys resources. More information about the options is available in the AiiDA documentation.

Restarting calculations

The main difference between a VaspWorkChain and a VaspCalculatio is that the former implements a basic logic of restarting failed or unfinished calculations. The framework of BaseRestartWorkChain is used with a set of predefined handlers to fix some (but not all) common pitfalls, such as restarting an ionic relaxation that has run out of the wall time and electronic convergence issues.

Once a calculation is finished, the CalculationNode is inspected by a series of aiida.engine.process.workchains.restart.process_handler(), which are executed in the order of descending priority. Each handler may be tied to a specific list of exit_code that the calculation may have. If any problems are found, and the restart can be performed, a ProcessHanlderReport would be returned and added to a list. If the break attribute of the report is set to True the handling process would be terminated. Afterwards, the last report is inspected. If it has an none-zero exit_code the, then the workchain will be aborted with that exit_code returned, this corresponds to the case where the error cannot be corrected automatically. Otherwise, it is assumed that calculation should be restarted with the revised inputs.

The flow chart below illustrates how it works coupled with the emittion of the ProcessHanlderReport from the handlers:


For more information, please see the docstring of BaseRestartWorkChain.

One should note that the hanlders included here are not intended to give a comprehensive coverage of all of possible errors from VASP, but instead we focus on improving the robustness by performing simple corrections that would be the right things to do in most times.

New handlers may be registered by adding the method to :py:class`~aiida_vasp.workchains.vasp.VaspWorkChain` with the process_handler decorator. Alternatively, one can also extended the VaspWorkChain by sub-classing and add more handlers there.