10. Run the batch

10.1. Local demonstration path

The local manager runs until the workspace is idle. Configure the tutorial mock as the VASP command; it writes the same output-file contract as a finished vasp-relax job, but its numbers are canned demonstration values, not physics.

httk workspace settings set --key vasp.command \
    --value "$PWD/docs/tutorial/data/mock_vasp_catio3.py" default
httk workflow run --workers 2

run is the local executor here: it prepares, runs, and publishes every job, then exits when no work remains. On a real VASP machine, use the same flow and set the command to vasp_std or to the site launcher, for example:

httk workspace settings set --key vasp.command --value "srun -n 32 vasp_std" default
httk workflow run --workers 8

The mock deliberately emits demonstration numbers chosen for the phase-diagram exercise. They are not calculated material energies.

10.2. Cluster variant

For a real cluster, configure an SSH remote once and transfer the complete batch. The remote is only the path to the machine; manager launch belongs to the workspace. --job is repeatable; list every page-09 job so the whole batch moves:

httk workflow remote add --template ssh kappa
httk workflow remote configure \
    --set host=kappa.example.org --set username=rar kappa
httk workflow remote check kappa
httk workspace init kappa:runs
httk workflow launcher add --template slurm --global cluster
httk workflow launcher check cluster
httk workspace settings set --key manager.launch --value cluster kappa:runs
httk workspace settings set --key slurm.partition --value batch kappa:runs
httk workspace settings set --key slurm.time_limit --value 01:00:00 kappa:runs
httk workspace settings set --key manager.workers --value 8 kappa:runs
httk workspace settings set --key environment.prelude --value "module load httk vasp" kappa:runs
httk workspace settings set --key vasp.command --value "srun -n 32 vasp_std" kappa:runs

httk workflow transfer \
    --job ca --job cao --job catio3 --job o --job ti --job tio default kappa:runs
httk workflow run --workspace kappa:runs --count 1
httk workspace status kappa:runs
httk workflow transfer kappa:runs default

ssh runs the adapter’s commands through a non-interactive shell, so module load lines and virtualenv activation from your login shell don’t apply there, and httk may not even be on PATH. Put that setup in the remote’s prelude instead of ~/.bashrc — it runs under set -e ahead of every command the adapter sends, including the probe remote check uses; when only the httk binary lives somewhere nonstandard, the narrower httk_command=/path/to/httk setting is enough. This adapter prelude is distinct from the environment.prelude workspace setting above: the adapter prelude bootstraps the shell so httk can run at all, while environment.prelude is applied later by the manager once it is already running on kappa.

httk workflow remote configure --set prelude='module load Python/3.13.5-bundle
source ~/venv/bin/activate' kappa

The manager can advertise the resources available in the cluster allocation:

httk workflow run --workspace kappa:runs --workers 4 \
  --worker-resource procs 32 --worker-resource mem 128000 \
  --worker-resource matlab_license_slots 2

Jobs that require a resource this manager does not have remain idle and are listed in its summary; in a Slurm allocation, procs, gpus, nodes, and mem can be derived from the allocation when not specified.

The reverse transfer brings finished jobs home; run the local collector in the next step. workspace init kappa:runs creates the named workspace on kappa, so its name is resolved by kappa rather than by the local machine.

See the launcher authoring guide and workflow CLI guide in the versioned httk-workflow documentation for cluster-specific options.