Simulation Guide
Knowledge Guides /How to Start and Stop Simulation Runs Reliably: Initialization, Stepping, Pausing, and Completion
Last updated: · New Horizon Digital Outsourcing Team
Simulation control needs explicit rules for transitions among configuration checking, initialization, readiness, execution, pause, and completion. Each transition should have confirmation from the execution side and retain any failure reason. Include simulation time, cycle number, and run identity in state feedback, and manage execution and output with explicit completion conditions.
Treat Initialization as a Separate Readiness Check
- Before initialization, check that scenario files, algorithm components, node identities, and required services are present, and confirm the configuration version actually used by each execution node. Connection establishment and configuration receipt are separate checks: a connected indicator does not establish that the current run data has been loaded.
- Retain an initialization result for every required node and enter the ready state only when the agreed conditions are met. If a node lacks a file or fails initialization, identify it, explain the corrective action, and prevent the run from starting. Reinitialize after correction so the operator can confirm that preparation has been repeated for this run.
Specify Stepping, Continuous Execution, and Pause
- Define whether a step advances one scheduling cycle, one solver call, or an agreed time interval. After a step completes, verify consistent updates to cycle number, simulation time, and output state. Disable conflicting step controls during continuous execution to avoid unintended advancement from duplicate commands.
- Define the boundary at which a pause takes effect, such as after the current cycle, and show a paused state only after execution confirms it. Display refresh, simulation clocks, and physical equipment may run at different rates; pausing simulation does not establish that equipment has stopped. For physical integration, separately specify the equipment's safe state and how it is confirmed.
Activate Configuration Changes at a Defined Point
- Bind a scenario configuration to a run and distinguish uncommitted edits, distributed values, and values adopted by execution nodes. If editing during a pause is allowed, specify editable fields and changes that require reinitialization. Record old values, new values, and the activation cycle rather than retaining only the final file and losing the run history.
- For distributed execution, confirm that required nodes received the same change before resuming at the agreed boundary. If a node has not confirmed, retain a pending state rather than inferring that all nodes are updated. Check configuration version, time, and output in the first resumed cycle to detect continued use of old settings.
Confirm Completion with an End Record
- Record normal completion, operator stop, execution failure, and timeout termination separately, retaining the final cycle, last valid time, and reason. A current cycle or output writes may still be in progress after a stop request, so distinguish stopping from stopped. Set a finite execution budget and define what happens when it is reached.
- During acceptance, exercise initialization failure and retry, switching from stepping to continuous execution, pause and resume, and operator stop. Check whether reopening a scenario retains unintended state from a previous run. Verify that logs, result files, and the end marker belong to the same run. Label partial results from aborted runs so they are not compared as completed conditions.