httk-workflow¶

This site documents the httk-workflow module. For the full documentation of httk₂, see docs.httk.org.

The module implements a recoverable, language-neutral workflow protocol whose source of truth is a single atomically renamed state marker per job. It presents three layers, each with its own import home: the filesystem protocol (httk.workflow.protocol), the execution and authoring surface (httk.workflow — Runner, Attempt — with lower-level helpers in httk.workflow.runtime), and orchestration and management (Workspace, TaskManager, harvest, and named submodules for transfers, remotes, and compatibility). Installations register the canonical httk workflow command tree, plus the httk-taskmanager and httk-v1-taskmanager executables, which are aliases of it.

Quick links

New here — start with Quickstart: five commands from an empty directory to a finished relaxation, no runner written and no VASP required.

The filesystem protocol — the language-neutral on-disk contract

The filesystem protocol API — the httk.workflow.protocol namespace
Workflow filesystem API — the normative on-disk specification

The execution API — writing and running workflow steps

Native runner helpers — the Python authoring SDK: Runner, Attempt, steps
Native Bash runner API — the same surface in Bash
Python and Bash authoring parity — the normative table both of the above must agree with
Packaged VASP runners — the packaged runners, for campaigns that write none
Workflow declarations — saying what a workflow is, for a data layer
Importing workflows written elsewhere — running PWD and CWL documents as ordinary jobs
Examples — worked examples as a notebook

Orchestration and management — driving and inspecting a workspace

Task-manager usage — workspaces, submission, managers, inspection, repair
Project and workflow command line — the whole httk workflow tree: projects, config, remotes
Campaigns — partitioning a very large campaign across many workspaces
Scale benchmarks — measured local scale snapshot and benchmark methodology
Harvesting results — reading finished jobs back out as records
Writing a remote adapter — reaching a machine the packaged adapters do not cover
Reference — the generated API reference

Migration

Install¶

Preferably work in a Python virtual environment:

git clone https://github.com/httk/httk-workflow
cd httk-workflow
python -m pip install -e .

Minimal setup¶

One workspace, one job of a packaged runner, and one manager that runs it:

httk workflow workspace init workflow-workspace --remote local --path workflow-workspace --extension transactional-data-v1
httk workflow job new workflow-workspace --template vasp-relax --from POSCAR --tag silicon
httk workflow manager run workflow-workspace --until-idle
httk workflow harvest workflow-workspace

Quickstart walks through exactly those commands, including how to run them without VASP installed. A complete payload prepared some other way is still submitted directly:

httk workflow job submit workflow-workspace prepared-job --placement project/00

Documentation