Runs

​

Overview

A run is one execution of a simulation model — the model, an optional schedule, and the full dataset of results the simulation produced. Runs are how you turn a model into numbers you can read: throughput, cycle times, utilizations, WIP, queues, resource activity, and every other measure the model is instrumented for.

​

Where Runs Live

Runs belong to a simulation model. Open the model in the Modeler and use View latest to inspect its newest replayable run, summary, and event log. To open an earlier run, ask Dexter for its link. Old Results links open the same model and run in the Modeler. For a dashboard, use the Simulation results app template or ask Dexter for results analysis.

​

What a Run Contains

• The inputs it was executed against: the model as it was configured when the run executed, and the schedule that drove it, if one did (arrivals, shifts, changeovers, or whatever the schedule carries for that model). A run names its schedule when one drove it, so the conditions behind the numbers are unambiguous.
• The raw simulation dataset: the low-level events the simulation emitted — entity lifecycles, process activity, resource activity, and related tables. This is the source of truth for anything derived from the run.
• Derived KPIs and charts: the KPI queries and chart queries defined on the model, computed against the run’s dataset. Dexter can read these saved results or query the dataset for an app or report.

​

Statuses

A run executes asynchronously in the background. Its raw dataset lands when the simulation finishes, and Dexter surfaces the run once the dataset has landed and its derived results are computed. Once a run has landed, its raw dataset stays valid. What can vary is the derived-results state — the KPI and chart computations layered on top:

• Pending: KPIs and charts are still computing after a fresh run or after query edits. Wait, then reload.
• Ready: KPIs and charts are computed and ready to read.
• Failed: the derived computation hit an error while the run and its dataset stayed valid. Ask Dexter to recompute; the simulation itself does not need to re-run.

​

Triggering a Run

Runs are created from a model. There are two entry points:

• Ask Dexter. “Run the baseline schedule on the Line A model”, “run the peak-week schedule three times” — Dexter kicks off the run against that model and schedule and surfaces it once it lands. This is the usual path.
• The Modeler’s Run control. The Modeler canvas carries a play button that starts a run of the model you’re editing without switching to chat. It reads green when the model passes validation and red when a blocker remains; hover the blocked control to see the error, and use Fix with Dexter to hand it to Dexter.

A single model typically accumulates many runs over its life: baseline, variants of the schedule, parameter tweaks, and comparisons after a model edit.

​

Reviewing Results

Open a run in the Modeler to inspect its replay and event log. For KPIs and charts, start from the Simulation results module template, connect it to the run, or ask Dexter to build the view you need. For deeper analysis, Dexter can query the run’s dataset tables directly and produce ad-hoc charts, tables, or a report from them.

​

Comparing Runs

To answer “how does X change if we vary Y”, run each variant as its own run. Edit the model between runs, switch the active schedule, or ask Dexter to copy the model and change the copy so the baseline stays intact. Each run records the model and schedule it executed, so the results stay attributable after the model changes. To see several runs laid out together, ask Dexter to compare them: it queries their results together and returns a comparison chart, table, or report.

​

Replications

To measure variability from randomness alone, run the same configuration several times with different random seeds. Ask Dexter (“run the baseline with 10 seeds”) and it launches the replications as one batch of runs, then compares their KPIs to show the spread. A fully deterministic model produces identical replications, so there’s no spread to measure.

​

Pipeline Runs Are Different

Pipelines prepare data, and each time one executes it creates a pipeline run. Pipeline runs have their own states and history on the pipeline’s page on the Data page’s Pipelines tab. They are separate from simulation runs opened in the Modeler, and a simulation run never shows up on a pipeline.