Analysis & Jobs
Run plugin workflows on trajectories and follow the execution model behind them.
An analysis is a persisted run of a plugin workflow against a trajectory. Every run is stored as a record with linked trajectory context, status, progress, and result exposures. Runs can be revisited to compare results, retry failed frames, inspect listings, or load a generated 3D artifact into the viewer.
Starting a run
The analysis tab inside a trajectory selects a plugin, configures parameters, and launches the run. Execution is dispatched to the cluster runtime: the workflow is planned, frame work is queued, and progress streams back into the UI.
Listing
The analysis listing is a history of executions, not a library of templates. Each row reports the plugin, the target trajectory, the progress, and the final state.
| Status | Meaning |
|---|---|
| Queued | The analysis exists, but workers have not started processing its frame work |
| Running | One or more frames are actively being processed |
| Completed | The full run finished successfully |
| Failed | Some frame work failed and can be retried selectively |
Frame-based progress
Most analyses are frame-aware workloads. A run can represent many individual frame jobs, and the progress bar reflects that breakdown. A partially successful run is still useful: only the failed portion needs to be retried.
Real-time updates arrive over the same event-driven layer used by the rest of VOLT.
Retrying failed frames
VOLT requeues only the failed frames for a given analysis. This avoids re-running already-completed frame work for heavier plugins.
Results, exposures, and exports
Completed analyses write results into cluster storage and project them into VOLT in several forms:
| Form | Description |
|---|---|
| Listings | Structured tabular views of the output |
| Sub-listings | Focused slices of a larger result |
| Charts | Visual summaries exported by the plugin |
| 3D artifacts | Overlays loaded back into the trajectory viewer |
Most of these start as MessagePack data and are transformed into the representation the UI requires.
Jobs layer
The Jobs system is the operational side of analysis. It tracks work across the team and provides a dedicated view for queue activity, running jobs, and retries.
The hierarchy is:
- A top-level analysis session.
- Grouped work tied to a trajectory.
- Frame-level jobs performing the processing.
The Jobs panel is team-wide and reports queue activity across all workspace members in real time.
Team-wide job actions
The jobs interface exposes maintenance actions for queue history: clearing history, retrying failed work, and removing stale running jobs.