FAST-HEP separates workflow definition from workflow execution.
The workflow language describes:
Execution backends determine:
This separation allows the same workflow to run across different execution environments without changing the analysis definition itself.
The current FAST-HEP alpha implementation primarily targets:
Execution planning currently focuses on:
The backend layer is still evolving as the ecosystem stabilises.
Local execution is intended for:
Typical usage:
fasthep run author.yamlThe workflow is compiled, planned, and executed locally without requiring external schedulers.
FAST-HEP is designed to support distributed execution through interchangeable backends.
The primary near-term distributed target is Dask.
Planned and experimental integrations include:
| Backend | Purpose |
|---|---|
dask:local | local distributed execution |
dask:htcondor | HTCondor-backed worker scaling |
dask:dirac | DIRAC/grid-integrated execution |
These integrations are still evolving and should currently be considered experimental or planned functionality.
Strategies are a planned mechanism for injecting backend-specific execution behavior into workflows without modifying the workflow definition itself.
The goal is to allow analyses to tune execution for specific environments while preserving workflow portability.
Possible use cases include:
Strategies are still under active design and should currently be considered work in progress.
Strategies are intended to customise execution behavior rather than redefine workflow semantics. The analysis workflow should remain portable across backends where practical.
Potential future execution targets include:
At present, FAST-HEP focuses primarily on internal workflow planning and runtime orchestration.
FAST-HEP intentionally distinguishes between:
The planner determines:
The backend determines:
This distinction is central to the FAST-HEP architecture.