Simulistics

"Disaggregation" refers to modelling in which some component is divided into a number of parts. For example, a lumped (non-disaggregated) model of soil water dynamics might use a single compartment to represent the amount of water in the soil. A disaggregated version of the same model might divide the soil into a number of layers, and represent the amount of water in each layer. Or: a population may be divided into age-classes; an area may be divided into subareas; a single "vegetation" component may be divided into the separate species.

System Dynamics is nothing more than a palatable front-end to a set of Differential-Algebraic Equations (DAEs): i.e. a set of differential equations, with a set of subsidiary algebraic equations for defining intermediate and rate quantities. Each compartment is a state variable, and each flow contributes to the rate-of-change expression for the associated state variable(s).

System Dynamics (SD) is a widely-used graphical notation for representing continuous systems. A System Dynamics diagram typically contains four main types of element: compartments, flows, variables and influences. Compartments represent storages of material, and the flows represent movement of the material into, out of and between compartments. Simile was designed as a 'System Dynamics plus objects' language, so naturally it is straightforward to represent standard SD models in Simile.

This chapter describes the standard simulation modelling approaches and how Simile fits in.

When you save a Simile model, it is saved as a text file in Prolog syntax. While it is not (and is not meant to be) human-readable, the format for this file is totally transparent. Anyone (with access to a Prolog programmer) can write programs for working with this file. One example is the Simile html model-description generator, a stand-alone Prolog program which produces an html file giving a complete description of any Simile model from the saved-model (.sml) file.

Simile generates a computer program for running the model. It is possible to wrap this program up (for example, as a DLL or as a COM component) so that it can be embedded in other software systems. One example would be for a GIS which is capable of having software modules embedded inside it.

In most, if not all, other modelling environments, you as the user are stuck with the input and output (display) tools provided by the software developers. This may not matter much if you are working in a specialised area such as electronics. It matters quite a lot for a generic modelling environment, when the range of systems that models can be developed for is so vast, and users requirements for visualising the behaviour of the model are so varied.

Simile's submodel concept provides a flexible but powerful approach to modularity — building a model up from a number of modules or components. At one extreme, Simile supports plug-and-play modularity: you can simply load a submodel, select an interface file, and all the links between the submodel and the main model are automatically made. This enables a community of researchers to agree on an interface standard, then engineer submodels to that standard.

Simile simulates the behaviour of models by generating a computer program and then running this program. The standard language used is Tcl/Tk, which is an interpreted language and hence does not run particularly fast, roughly of the same order as other visual modelling packages. However, if you have a recommended C++ compiler installed, then you can simply choose to run the models in C++ : the whole run-time environment is identical. Models then run several hundred times faster : in many cases, roughly at the same speed as hand-written C programs.

Simile is capable of handling models with several hundred equations. It is also capable of handling models with large number of instances (tens of thousands) of the same type of object. Both aspects mean that you do not hit a bottleneck as you move from prototype models to serious research models.