Experiments and Runs

A single simulation run answers very little. What you actually want to know — does the buffer between the two stations need ten places or twenty — is a question about several runs compared against each other.

The Experiments window is where that comparison is organised. It shows one tree:

Project
└── Experiment
    └── Run
        └── Checkpoint

Each level answers one question:

Level	What it is
Project	The comparison boundary. Runs are only ever compared within one project.
Experiment	One scenario under test. A changed model structure starts a new experiment under the same project, so results from two different models are never mixed into one chart.
Run	One execution, with its seed, its status (completed or aborted), when it started and ended, the simulated time it reached, and its statistics.
Checkpoint	A stored simulation state inside a run, which can be loaded and continued.

Every experiment of the active project is visible at once. Experiments recorded against a different version of the model are marked with a quiet other model version chip rather than being hidden — you can still see them, you just know not to compare them.

Opening it

Two entry points, both toggling the same window: the Experiments button in the DES clock settings, and the DES side-tool button.

The DES Experiment Matrix window over a turntable loop: the CRN switch and Run All in the title bar, one column per experiment with the baseline selected and New Experiment next to it, and the Run, Parameters and Results (KPI) sections listing seed runs, sim end, warm-up, status, parameter overrides, throughput and mean utilization

Seeds and repeatability

A run’s seed is what makes it repeatable. Re-running the same seed produces an identical result, and the archive treats it as such: the run overwrites its earlier twin rather than adding a duplicate.

Two modes:

Fixed seed — every reset runs the same seed again. Use it when you are changing the model and want the randomness held still.
Auto seed — every reset rolls a fresh seed and therefore creates a new run. This is what you want when you are collecting replications of the same scenario to average over.

The seed itself is part of the model: it lives on the document’s DES manager and travels with it. Whether you are in fixed or auto mode is a personal preference stored in your browser, not in the model.

Checkpoints

Checkpoint autosave stores a full simulation state at regular simulated-time boundaries — every hour of simulated time, say, landing exactly on 04:00:00, 05:00:00 and so on rather than wherever a frame happened to fall. It is off by default; set an interval to switch it on.

Because the boundaries are placed in simulated time, they land at the same points in Animated, Fast-Forward and Step mode alike, and a seeded run produces bit-identical results whether autosave is on or off. Changing the interval while a run is going re-plans the next boundary immediately.

A run keeps its newest checkpoints in a ring buffer of configurable size; older ones fall out. Loading a checkpoint restores the state and the random number streams, and drops the simulation into Step mode so you can walk forward event by event from there.

If the store comes under pressure — Fast-Forward can produce checkpoints faster than they can be written — an individual save at a boundary is skipped. The schedule itself never breaks, and a skipped boundary is not made up later.

Comparing runs

Tick the runs you want to compare — anywhere in the tree, across experiments — and the comparison view reports their combined statistical result as mean ± 95 % confidence interval. That is what a set of replications is for: it separates a real difference between two scenarios from the scatter within one.

Comparison is strictly project-internal. Runs from different projects are never combined.

Managing the tree

Project — select, create, rename, or delete with everything below it.
Experiment — take a snapshot now, export, rename or delete.
New experiment — a field at the bottom of the window creates one, optionally taking a first snapshot straight into it.
Import and refresh sit in the title bar.

The model an experiment belongs to is shown by name. The internal fingerprint that decides whether two experiments describe the same model never appears in the UI.

Export and import

One experiment travels as a single compressed file containing its manifest and every snapshot in it. Import reads it back; if the name already exists, the imported experiment is renamed rather than overwriting anything.

This matters more than it sounds. Everything the Experiments window stores lives in browser storage, which is a cache the browser is allowed to reclaim — Safari, for instance, evicts unused site data after seven days. The window shows the storage you are using and warns as you approach the quota, but export is the only durable path. Export what you want to keep.