slurm-workflows: HPC workflow helpers for Slurm clusters
slurm-workflows runs Python functions on a Slurm cluster
from a Python script.
It provides an interface
inspired by concurrent.futures.
The interface launches long-lived workers inside pilot jobs.
It then dispatches tasks to those workers.
You pay Slurm's scheduling latency once per pilot job.
Every later task runs on a worker that started earlier.
Use it in three cases:
- You have one Python function to run over many inputs on one cluster allocation.
- You have many Python tasks to run, some of which wait on others.
- Per-worker state is expensive to build, and you want to keep it between tasks.
For a search over a parameter space, use
slurm-workflows-optimize,
which builds on this package.
Installation
A run needs Slurm's sbatch, squeue and scancel,
and the ds-service binary, on PATH.
pip install -U slurm-workflows
To install on UVA's Rivanna cluster, read How to install slurm-workflows on Rivanna.
Usage
Replace the Slurm account (-A), the partition (-p)
and the setup script with the ones for your cluster.
The driver, the Python script that uses the executor,
must run on a node with the ib0 interface.
For another interface, read
How to run the ds-service server.
from ds_service_client import DsServiceServer
from slurm_workflows import SlurmPilotExecutor
def square(x):
return x * x
SETUP_SCRIPT = """
module load miniforge/26.3.2
conda activate slurm-workflows
"""
# The network interface the workers can reach.
with DsServiceServer(interface="ib0") as ds_service:
ds_service.wait_until_ready()
with SlurmPilotExecutor("my-run", ds_service.address) as executor:
# 1. Describe a job group. This submits nothing.
executor.define_job_group(
name="cpu",
sbatch_args=["-A my_alloc", "-p standard", "-t 01:00:00"],
setup_script=SETUP_SCRIPT,
)
# 2. Launch 4 pilot jobs of that job group.
executor.scale_jobs("cpu", 4)
# 3. Map `square` over the inputs on the "cpu" job group's workers.
# The call blocks until every value is back, in input order.
squares = executor.map("cpu", square, range(100))
# The executor canceled every pilot job at the end of the block.
print(sum(squares))
work directory: '/home/<user>/.cache/slurm-workflows/my-run/<timestamp>'
328350
map blocks, and hands its inputs to the workers as they start.
For one value instead of a list, map_reduce folds the values on the workers.
For a handle per task, submit enqueues one task and returns at once,
even before the workers exist.
To choose between them, read The pilot-job model.
Documentation
| Type | Document | What it covers |
|---|---|---|
| Tutorial | Computing pi on a Slurm cluster | The main features of slurm-workflows, by using map_reduce on a pool of workers to compute $\pi$. |
| Tutorial | Computing pi with submit and wait |
The advanced interface: one task at a time, with task names, priorities, parent tasks and a failure policy. |
| How-to guide | How to install slurm-workflows on Rivanna | Installing the package and the ds-service binary on Rivanna. |
| How-to guide | How to run the ds-service server |
Starting a ds-service server from the driver and binding it where workers can reach it. |
| How-to guide | How to keep per-worker state with actors | Loading an expensive model or connection once per worker instead of once per task. |
| How-to guide | How to watch a run with swtop |
Following a live run from another shell, and keeping a record of one. |
| How-to guide | How to embed swtop in a Textual app |
Putting the swtop tabs, summary line, progress bar and error line in your own Textual app. |
| How-to guide | How to troubleshoot a failing run | Finding the right log, and what each RuntimeError means. |
| How-to guide | How to update worker code without resubmitting | Restarting the workers in running pilot jobs, so they run new code without a second wait in Slurm's queue. |
| Reference | map |
Mapping an iterable across the pool and getting every value back in order. |
| Reference | map_reduce |
Mapping an iterable across the pool, the fold contract, and what the call creates on the server. |
| Reference | submit, wait and as_completed |
The advanced interface: submit options, Task, RaiseOnError, and the errors that end a wait. |
| Reference | SlurmPilotExecutor |
The executor, the job group options, restarting workers, and the worker entry point. |
| Reference | What a run publishes | The keys and time series a run writes, and the logs. |
| Reference | swtop |
The CLI, the keys, the blocks on screen, and what the host and job readings measure. |
| Reference | slurm_workflows.swtop_widgets |
The swtop widgets and the poller an app can embed. |
| Explanation | The pilot-job model | Why pilot jobs, the three processes, where the driver runs, and the two interfaces. |
| Explanation | The monitoring state a run publishes | Why a run is observable from outside itself, and the limits of that. |
For contributors
| Document | What it covers |
|---|---|
| Developer notes | The layout of the code, where each kind of documentation goes, and the conventions a change must follow. |
| Terminology | The word this project uses for each concept, in prose and in identifiers, and where each word comes from. |
| How to run the tests | Running the suite, what it mocks, and what it runs for real. |
License
MIT. See LICENSE.
Metadata
Release files for slurm-workflows 5.1.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | Actions |
|---|---|---|---|---|
| slurm_workflows-5.1.0.tar.gz | 56.8 kB | Without provenance | Details for slurm_workflows-5.1.0.tar.gz |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| slurm_workflows-5.1.0-py3-none-any.whl | Python 3 | none | any | Details for slurm_workflows-5.1.0-py3-none-any.whl |
Total release size: 120.3 kB
Release files / slurm_workflows-5.1.0.tar.gz
| Download URL | slurm_workflows-5.1.0.tar.gz |
|---|---|
| Size | 56.8 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
20138aecc48bb4addbeb289504adec685c743192912e5ae16798c0e909eac7cd
|
|
BLAKE2b-256 checksum How to use checksums |
fcc27f8811fe7a9aad99b43e57bf52415e5c84a98fb721bc67c1cfad52321243
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.15
|
Release files / slurm_workflows-5.1.0-py3-none-any.whl
| Download URL | slurm_workflows-5.1.0-py3-none-any.whl |
|---|---|
| Size | 63.5 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
ebfc8ceabc72290b01eb52c25549b801f4993a21780769348f4f9994b07e680a
|
|
BLAKE2b-256 checksum How to use checksums |
e3d68d90d7a5f661f41161436626c5d69d5076f6d2f3d9d685017f703595cbbc
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.13.15
|
Security for slurm-workflows 5.1.0
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
To learn more about protecting yourself from malicious actors, visit our package security documentation.