- Products and services
- Resources and support
- About us
- Log in/Register
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.