Case study / 02
DASH-X
Cloud simulation and analysis workflows
Developed at InterDynamics, DASH-X supports simulation studies from scenario preparation through repeated runs, statistical analysis and result inspection. It was designed around Planimate Monte Carlo workloads, while allowing configured Windows and Linux executables to run within the same workflow.
The Angular and .NET management application organises projects, studies, scenarios and phases, and manages project access. A separate Azure Container Instances controller executes configured Windows or Linux workloads. Independent simulation runs can execute concurrently, followed by an optional configured analysis phase. Cosmos DB stores application metadata; Blob Storage holds input and output files.
Application metadataBlob Storage
Input and output files
01 / Operational context
From individual runs to simulation studies
A simulation study often needs more than a single result. Analysts run the same scenario with different random seeds to examine the distribution of possible outcomes, then compare scenarios representing different operating assumptions.
Before DASH-X, users typically started those runs manually, exported the outputs and assembled them for analysis in their own scripts or Excel. They also needed access to enough local computing capacity to complete the work.
DASH-X brought preparation, execution and access to results into a shared application. InterDynamics could configure projects for customers to use directly, or use the platform internally to carry out studies and prepare client reports.
02 / Analyst workflow
Projects, studies and scenarios
I designed the application structure around the way an analyst organises work. A project represents the system under investigation, such as a supply chain. Within it, a study contains the scenarios to be compared, each with its own inputs.
Project managers define workloads, typically representing a particular simulation version. Users upload scenario input files and, where the project is configured for it, edit those files within the application. Existing scenarios can be duplicated to prepare further alternatives.
My responsibility covered the management application’s design and implementation: the Angular interface, application backend, database structure, cloud architecture, project membership and roles, and access to input and output data.
03 / Execution and analysis
Repeated runs followed by post-processing
A scenario can contain multiple execution phases, with one phase’s outputs becoming inputs to the next. For a Monte Carlo study, the first phase runs the simulation repeatedly with different random seeds. A second phase can execute a configured process that consolidates those outputs and calculates statistics.
Each run’s status is recorded. A subsequent phase can require a minimum number of successful runs before proceeding, allowing the analyst to set whether incomplete results are sufficient for further processing.
The resulting data can be inspected through a spreadsheet-style interface, with charts created from the outputs. All output data is also available for download and external analysis or report preparation.
04 / Architecture
Separate application responsibilities from compute control
A colleague developed the core Azure Container Instances API for creating and removing containers, staging data, starting workloads and collecting outputs. The application keeps project organisation, user access and analytical workflow decisions outside the controller.
That separation allowed the controller to remain reusable across applications. DASH-X itself is not restricted to Planimate: workloads can use Windows or Linux executables, provided they are configured to read inputs and write outputs in the form expected by the execution environment.
Input and output files are held in Blob Storage. These datasets can be large, their structure varies between projects, and the application did not need database queries over their contents. Application metadata is stored separately in Cosmos DB.
Azure Container Instances allowed compute resources to be sized for individual runs. The simulation workloads were single-threaded, so each run could use a small container.
Independent runs can execute concurrently rather than sequentially. For example, 100 runs taking ten minutes each would require around 1,000 minutes if executed one after another. With sufficient cloud capacity to run all 100 concurrently, the simulation time could approach ten minutes, plus container startup, data transfer and other orchestration overheads.
05 / Verification and use
Supporting client analysis and reporting
Initial comparisons checked cloud execution against local runs, particularly Linux command-line execution against the Windows graphical application. For one client with an existing cloud system, comparisons also established equivalent simulation results before InterDynamics used DASH-X to perform analysis and prepare reports for them.
In consulting work, the platform supported studies involving 10–20 seeded runs or 10–20 scenarios, with consolidated outputs used to report distributions around the results.
Client users who tried DASH-X reported a more responsive interface than their existing system and valued the ability to include post-processing in the workflow. Its practical value to InterDynamics has been supporting the analysis and reporting work around a simulation, alongside supplying the model itself.