OSDL and Modelica

Modelica and OSDL both describe simulation models, but they target different problems and make opposite choices about how model behaviour is written. Modelica is an equation-based language for continuous, physical systems. OSDL is a component-based document format for discrete-event, agent-based, and system-dynamics models. This note compares the two, prompted by an article on when Modelica needs algorithm sections rather than equations.

How Modelica expresses behaviour

Modelica has two mechanisms.

Equations state relations that are simultaneously true. Writing a = b + c is a relation, not an assignment. The compiler collects the equations from every connected component, sorts them, derives causality, and solves the resulting system of differential-algebraic equations numerically. This is acausal: the tool decides what is input and what is output. Connections between components are acausal too, in the Kirchhoff sense, generating equations across the boundary. Equations are the centre of the language and the reason it suits electrical, mechanical, and thermal modelling.

Algorithm sections hold imperative, sequential statements: assignments with :=, loops, and conditionals, executed in order. They are the right tool for numerical procedures, for example Newton’s method, where the order and the repetition are the point, and for function bodies. The article’s line is that an algorithm is part of the language, not the centre of it. Equations stay the default; algorithms serve specialised computational needs.

How OSDL expresses behaviour

OSDL makes different choices.

There is no acausal equation solver. OSDL has no construct where you declare simultaneous relations and let a solver find causality. Ports and connections carry directed entity transfer and signal coupling, not acausal connectors. Modelica’s core mechanism has no OSDL equivalent, so acausal physical modelling stays Modelica’s domain.

The continuous side of OSDL is causal. Its system-dynamics library uses stocks and flows. Each flow rate is written explicitly as an expression of the current state, and an integrator advances the stocks (Euler or RK4), updating them simultaneously each tick. This is the Forrester system-dynamics tradition of causal integration, closer to writing an explicit ordinary differential equation than to Modelica’s acausal equations.

Where a value must be computed, OSDL uses a small expression language that is total and side-effect-free, for example {"expr": "1 / treatmentTime"}. It is deliberately not Turing-complete: expressions terminate, hold no mutable state, and contain no loops inside the model document. Genuinely procedural logic lives inside component implementations, defined by the library and the engine, not in the model. This is the opposite of Modelica’s algorithm sections, which are full imperative code.

Comparison

  • Paradigm and domain: Modelica covers continuous and hybrid physical systems as differential-algebraic equations, with some discrete events. OSDL covers discrete-event, agent-based, and system-dynamics models and their hybrids, executed on one event calendar. The target domains barely overlap.
  • Acausal versus causal: Modelica derives causality by solving equations. OSDL is causal throughout, in its directed connections and its explicit flow rates.
  • The algorithm role: both need a way to compute values procedurally. Modelica exposes a Turing-complete algorithm language. OSDL restricts model-level computation to total, side-effect-free expressions and pushes procedural logic into components.
  • Guarantees: OSDL’s restrictions buy determinism, portability, and formal analyzability. It ships as a vendor-neutral JSON schema with an executable Lean reference machine defining the semantics. Modelica’s power comes with heavier tooling, including index reduction and DAE solvers, and is less amenable to deterministic, formally-checked replay.

The article frames Modelica as equations for relations that are true and algorithms for step-by-step computation. OSDL keeps the first half in its declarative component graph and expressions, and refuses the second half at the model level, keeping model values total and side-effect-free.

References