Main menu
You are here
System Dynamics modelling in the Modelica modelling language
I've been looking at a number of other modelling languages, primarily to see how models are represented in the language. One of these is Modelica, which is mainly aimed at the development of engineering-related models. A number of modelling environments, such as Dymola, are fully Modelica-compliant.
A typical Modelica model diagram contains symbols representing components such as electronic, hydraulic or mechanical components. For each domain, there is a Modelica library which contains not only the graphical definition of the symbol, but also its mathematical specification. This is represented in what is called an acausal manner - meaning that the inputs and outputs are not pre-defined. For example, a resistor is defined by the equation V = I.R, but a particular problem may require this equation be used to calculate R in terms of V and I.
This ability to define the mathematical nature of a symbol, and to do that in an acausal manner, is very elegant, but quite different from the approach typically used in biological/ecological/environmental modelling, which tends to use causal relationships (e.g. growth_rate = f(temperature) ), and to allow model builders to define the equations as they build the model.
One library is the System Dynamics library. This defines symbols for standard System Dynamics elements, such as stock (level, compartment), flow etc. It was originally developed by Stefan Fabricius, but has been totally revised by Francois Cellier, at ETH (the Swiss Federal Institute of Technology) in Zurich. The library has been used to re-implement the Club of Rome World2 and World3 models, as described here.
The attractive aspect of using Modelica for System Dynamics is that it is very straightforward to integrate System Dynamics models with those based on symbols from other domains, such as electronics and engineering. The downside, as I understand it, is that each different use of a System Dynamics symbol requires its own entry in the library. For example, a stock with one inflow and one outflow requires a different Modelica symbol from one with one inflow and 2 outflows. Also (again, as I understand it), every separate equation requires its own symbol to be defined and added to the library before it can be used. Both aspects represent a considerable limitation for the typical System Dynamics modeller, where both the diagramming and the equation entering are rather fluid aspects of the modelling process.
- robertm's blog
- Log in or register to post comments
Comments
System Dynamics Modeling with Modelica
The short introduction given here for the use of the Modelica langauge for System Dynamics modeling is too bleak and begs a revision which I will try to provide.
A major advantage of using Modelica is having an open source language for modeling which has support from industry and works with proprietary tools as well as with open source tools. Models can be run from different environments using the Function Mock-up Interface (FMI) standard, co-cimulation of different models and real-time simulation are possible.
While the inductive modeling approach ("fluid modeling of causal assumptions") of system dynamics modeling is not immediately supported in the graphical user interfaces of Modelica tools like Dymola or the Wolfram System Modeler, models can immediately entered using equations ("=") -- not assignments (":=") as in most SD tools -- and there is no need to use icons at all.
When System Dynamicists talk about "structure causes behavior" they are talking about logical structure and causation only (coming from control engineering). Essentially all System Dynamics models can be built using block diagrams in Modelica (this is the approach used by Cellier et al. in their freely available library). By doing this physical (acausal) structure is not faithfully modeled: If a stock is connected to another stock using a flow, then many SD tools will not show that "material connection" as only the "information" given as a rate equation counts (e.g. there is a + or - link from the rate to the stocks). Modelica uses acausal connectors which always come as pairs (potential/effort and a related flow). So a "material" connection is treated differently from a logical connection (information signals), while in many SD tools the double arrow is only "artwork".
System Dynamics Modeling with Modelica (Part 2)
Structure is hidden in System Dynamics because there is only arrows, circles and boxes. For example, the function performed by a converter is hidden as a "parameter". In Modelica we may have an individual icon so that what is performed by the converter is immediately visible in a diagram without having to "drill in".
Modelica's strength is enabling hierarchical, component-based modeling. Once a component is defined it can be reused simply by dragging and dropping it on the modeling canvas, then connecting it to other components. We even do not have to "drag and drop" a component by declaring it as replaceable. Testing different policies, for example, can then be done without having to change structure in the GUI - a great advantage for bigger and complicated models imo, as replacing components is far less error prone.
Of course, component-based modeling requires that we have to think about a subsystem's connectors. For example, modeling a supply chain, I might develop a generic class for a producer, that has logical inputs and outputs (e.g. managerial control) and also a "mass port" indicating a material flow. An intermediary in the supply chain would have logical inputs as well and will have an "in-port" and an "out-port".
Doing this in tools like Vensim, for example, is not possible. If I model a subsystem in a separate view, flows from supplier to distributor will have to end or start in or from a cloud - only the rate information can be ported to another view as a shadow variable. Thus many SD-tools hide important physical structure.
The burden of defining connectors is lifted quite bit as using records and arrays tremendously simplify building more complicated models.
Component-based modeling also means "write documentation only once" - reusing a component automatically links to the components-documentation and greatly helps developing and documenting bigger models.
Working with an open source tool also means working with a great community and lots of freely available libraries (see link posted above): There is neural networks, fuzzy logic and control, for example.
Modelica also supports hybrid modeling, as it has a very sophisticated discrete event machinery, where one can make use of the declarative expressiveness of state graphs. Variable structure modeling (aka Agent-based Modeling) is in development.
TL;DR Modelica is definitely worth a try for serious System Dynamicists that feel a need for reusable components and a hierarchical modeling approach. Using acausal connectors enables the modeler to use very compact components (e.g. no need to -- trivially -- feedback a minor loop whenever exponential growth is to be modeled); making use of acausal connectors for SD will require building a custom library, but may well be worth the effort. Having a powerful open-source language instead of proprietary tools is the way forward.
Simile vs. Modelica
There are a few points here I'd like to take issue with. It seems that
Modelica's graphical library contains a large number of symbols, while
System Dynamics has only a few that can be arranged to represent the
same range of functions, a bit like the Chinese and Latin
alphabets. Neither is intrinsically 'better'.
Simile allows hierarchical, component-based modelling. A model
consists of a hierarchy of nested submodels, and the interface between
a submodel and its surroundings can be saved in a separate
specification. The interface may consist of physical transports as
well as continuous and discrete information. This enables submodels
implementing alternate versions of the same function to be swapped --
see Plug-and-play modularity.
Simile's mechanism for implementing discrete events is unlike any
other graphical multi-modal simulation tool. Event occurrences are
modelled as happening at their exact time, rather than being rounded
to the nearest time step boundary. Models consisting purely of
discrete events and rule-based states do not even need a time
step. See Discrete event based modelling.
There doesn't seem to be a generally agreed definition of agent-based
modelling, so I propose that Simile's multi-instance submodels, which
include population submodels, and the ability to set up relationships
between individuals of the same or different submodels, covers it as
well as anything.
Finally we at Simulistics are great beleivers in open-source tools. We
are waiting for progress on the XMILE model exchange language in order
to fully support it in Simile. We would make Simile itself open-source
if we could find a business model that would work that way.
Simile vs. Modelica — A Reply to the Reply
Now, that is a completely misleading and utltimately false description: In Chinese each symbol has a unique meaning and you need to know thousands of symbols to write sentences. Using the Latin alphabet, a few symbols are sufficient to write sentences, paragraphs, and chapters. Modelica is exactly like Latin, there are a few atomic classes and everything is build upon these by flexible inheritance. The difference to System Dynamics tools is, that you need to write chapters using letters, while in Modelica and other object-oriented languages you can use pre-written sentences and paragraphs. That is ultimately more flexible and intrinsically more powerful—variety conquers complexity as cyberneticians have known for a long time.
You are "preaching to the choire" in pointing at how discrete-event modeling is done. Modelica meets industry standards for real-time control systems (e.g. controllers in aircraft), so there is no rounding to any nearest time step. For more details have a look here.
That is great to hear. But Simile is not defining an open-source language standard—the Modelica Association is doing exactly that with proprietary and open-source software choices. I do not see this in the SD community. While XMILE is a step forward, it is rather unknown when compared to the Functional Mockup Interface (FMI) available for Modelica, which is supported by heavy players in industry. While XMILE only supports model exchange, FMI also allows co-simulation of different models.
To see the advantages of Modelica, simply take a look at the new Business Simulation Library.