Operations are the primary executable units in FAST-HEP workflows.
An operation describes:
Operations are identified declaratively in workflows using an operation kind:
op: hep.defineThe actual implementation is resolved through registries during workflow compilation.
FAST-HEP separates:
Operations are the bridge between declarative workflow descriptions and executable analysis logic.
This allows workflows to remain:
Operations may perform many different tasks.
| Category | Purpose | Example | Typical package |
|---|---|---|---|
| sources | introduce external data streams | root_tree | fasthep-carpenter |
| transforms | derive or modify event data | hep.define | fasthep-carpenter |
| apply filtering and cutflows | hep.selection.cutflow | fasthep-carpenter | |
| aggregate or summarise event data | counters, reductions | fasthep-carpenter | |
| sinks | persist or aggregate outputs | histogram filling, ROOT/parquet writing | fasthep-carpenter |
| generate plots and reports | hep.render.data_mc | fasthep-render | |
| observers | inspect workflow state | schema snapshots | fasthep-curator |
| hooks | react to runtime lifecycle events | diagnostics, summaries | fasthep-curator |
The exact boundary between categories may evolve as the ecosystem matures, but the core separation of responsibilities between packages is intentional.
Rendering is currently registered as a sink because it consumes produced artifacts and writes visual outputs. It may become a more explicit operation category as the rendering API stabilises.
Example operation:
- id: BasicVars
op: hep.define
params:
variables:
- name: Muon_Pt
expr: "sqrt(Muon_Px ** 2 + Muon_Py ** 2)"This operation:
depends on:
Muon_PxMuon_Pyproduces:
Muon_PtFAST-HEP uses this information during dependency inference and planning.
- id: DiMuonMass
op: hep.hist
params:
axes:
- name: dimu_mass
source: DiMuon_Mass
type: regular
bins:
low: 60
high: 120
nbins: 60This operation consumes event-level quantities and produces histogram artifacts.
Histogram operations are commonly followed by rendering operations.
Rendering is usually attached declaratively to produced artifacts:
render:
style: dimuon_mass
when: finalRendering operations may produce:
The rendering implementation is resolved through registries and styles.
Operations are accompanied by specifications (“specs”).
Specs describe operation behavior in a planner-friendly and machine-readable form.
Depending on the operation type, specs may describe:
Specs help FAST-HEP reason about workflows before runtime execution begins.
Specs allow planners to understand workflows without executing analysis code.
This enables:
without requiring immediate data processing.
This separation is one of the key architectural ideas in FAST-HEP.
Operations often expose planner-visible behavior separately from runtime implementations.
For example:
runtime implementation
spec implementation
This allows planners to construct execution graphs before runtime execution begins.
Operations are registered through registries.
For example:
op: hep.histmay resolve to:
provided by fasthep_carpenter.
This resolution occurs during workflow compilation.
For more detail, see:
Operations intentionally avoid coupling workflows to specific runtimes.
The same operation definitions may eventually support:
without changing the workflow description itself.
Earlier FAST-HEP prototypes exposed some operation specifications as generated JSON artifacts.
This made planner-visible behavior easier to inspect and debug.
Future FAST-HEP versions may again expose richer spec artifacts and planner diagnostics as part of workflow introspection tooling.
Operations and specs intentionally separate:
This separation helps workflows remain: