Tasks¶
One of the primary goals of autojob is to enable the recovery of failed
jobs from the directory in which they were run. As such, the “task” concept
associates with each job an object that contains its state. In addition to
being able to instantiate a task programmatically, a central tenet of
autojob is that tasks should:
be instantiable from the directory in which the related job was run, and
be straightforwardly written to a directory in which they can be run.
The first goal is accomplished by the PathLoadable
protocol, which requires adherents to implement the from_directory method.
The latter goal is accomplished by the InputWriter
protocol, which requires adherents to implement to write_inputs method.
Both protocols are implemented in the abstract base class,
TaskBase, which represents an
atomic compute job.
The state of a task is represented by Pydantic model attributes. For the
simplest task, this includes inputs, outputs, and metadata. autojob also
defines several concrete implementations of
TaskBase:
TaskCalculationVibrationInfrared
Importantly, the latter three implementations inherit from subclasses of
TaskBase which feature additional methods
and attributes.
Further, users can define their own implementations of
TaskBase by inheriting from one of the
abstract base classes or from one of the concrete implementations defined
herein. Although passing custom implementations of tasks will work for all
methods which accept TaskBase instances,
in order for some of the magic of harvest to
function correctly (automatic instantiating of task subclasses) without
explicitly passing the custom class, users should register their tasks
using the plug-in system (TODO: write how-to).