There are a number of things Dymodetron wants to do, but doesn’t. In no particular order:
Easy ensembles of simulation runs¶
Constructs and features for configuring, executing, and analyzing ensembles of many runs of a simulation, sampling the random distributions on each run, in order to easily analyze the distributions of the simulation results. For now, this is left as an exercise for the user. This would be used to support the following use cases:
Random distribution sampling (running multiple “seeds” of a simulation with the same set of fixed parameters).
Sensitivity analysis using parameter sweeps and monte-carlo.
Model parameter calibration.
Generate simulation data for follow-on model reduction processes.
Multiple Entity Types¶
Support multiple entity types in a single model, each having their own distinct sets of state machines.
Support Additional Models of Computation¶
Models are built to answer questions. Different kinds of questions require different kinds of models. Different kinds of models require different underlying “models of computation”. There are a number of other models of computation that Dymodetron wants to support directly. These would need to be done in such a way that any given model could utilize multiple of them simultaneously. This requires the different notions of time and causality to be integrated together. In some cases you can kinda-sorta approximate these additional models of computation by implementing them inside a state machine, but that’s not the same thing and there will be limitations, negative performance implications, or both, on top of the extra effort required on the part of the modeler, and the fact that any such workaround will be a point solution, probably only useful for a single model, and hard for others to leverage. It would be better for the additional models of computation to be supported directly. Some key missing models of computation are listed below.
Ordinary, Stochastic, and Partial Differential Equations (ODE/SDE/PDE)¶
System states modeled using differential equations. Rate equation parameters can be modified by e.g. state machine events. Threshold crossings by e.g. ODE-calculated state values can trigger state machine events.
Stochastic Simulation Algorithm (aka Gillespie, SSA)¶
Stochastic simulation of sets of finite populations that vary in time. Reaction rates (propensity functions) are used to describe how the populations change in time. Similar to ODE model, but having quantized state values and rate equations capable of capturing e.g. local depletion/exhaustion; more valid when a continuum approximation is not appropriate.
Describe a sequence of activities, often with conditional logic. Different from a state machine, in that a state machine is “reactive” while a flow chart is more like “imperative”. In a state machine, the “boxes” are states that an entity can be in, and the arrows are transitions triggered by events that move entities between states. In a flow chart, the “boxes” are steps to take, and the arrows are sequencing of those steps and conditional logic that can take the flow down a different path. Flow charts are good for modeling e.g. a decision making process that involves a set of rules to be evaluated.
Data flow / process model¶
Similar to that supported by xarray-simlab. Imperative graphs of data processing.
Components and Interconnects.¶
Enable “model blocks” built out of the other Dymodetron constructs to be linked together and built up hierarchically into larger model blocks.
Additional model description elements.¶
Add more model description elements, such as author, references, links, etc.
Additional options for lookup table behavior.¶
Add options for out-of-range lookup values to either rail to a constant value or raise errors, instead of extrapolating.
Add ‘Exact’ lookup method that raises error if the input lookup value isn’t exactly a breakpoint.