Skip to content

AiiDA v1.4.0

Compare
Choose a tag to compare
@sphuber sphuber released this 24 Sep 11:10
59ebaf4

This is the fourth minor version of the v1 series and comes with some important performance improvements and features, but also various bug fixes. This is the last version to support Python 3.5.

RabbitMQ server can now be hosted on a different machine

In previous versions, AiiDA only supported connecting to a RabbitMQ instance running on localhost. With v1.4, one can now configure AiiDA to connect to a RabbitMQ instance over TCP/IP with optional SSL enabled. Existing profiles will be automatically migrated to add the standard configuration. To see how a new profile can be configured to connect to a remote RabbitMQ instance, please refer to the documentation.

Group extras

Groups now support setting "extras": just like nodes, you can now store arbitrary metadata on group instances, as long as it is JSON serializable. The interface to setting, getting and deleting extras on a group is exactly the same as that for nodes. Note that, just as they are for nodes, extras are mutable. It is therefore not advised to use them to store information that is important for data provenance.

Scheduler output parsing

This version comes with a new method for the scheduler base class Scheduler.parse_output that can be implemented by scheduler plugins to parse the output that is generated by the scheduler when running a calculation job. The output consists of the detailed job info (if implemented by the scheduler plugin) and the output written to the stdout and stderr file descriptors. This information can hold important information about how the job terminated. It can be used to determine common problems, such as out-of-memory issues or out-of-walltime errors. The parse_output can return a corresponding exit code that is defined on the CalcJob class. You can take a look at the SlurmScheduler.parse_output implementation as an example of how it parses the OOM and OOW errors. The scheduler output parsing, if implemented, will be called by the engine before the output Parser is called, if any. If the scheduler parsing returns an exit code, the engine will already set it on the node but the output parser will still be called. This allows the output parser to still try to parse some data from the retrieved files, and if desired, override the exit code of the scheduler with a more specific exit code. For details on this process and the interaction between exit codes of scheduler and output parsers, see this section of the documentation.