Simulistics

Modelling the individuals that constitute a population is an extreme form of disaggregation. It is being increasingly recognised as a highly effective approach, for two main reasons. First, it enables the modeller to capture interactions critical to system behaviour that are lost in any more aggregated approach. Second, it frequently is much easier to construct individual-based models, since the behaviour of and interactions between individuals are frequently quite simple, but can lead to complex patterns of behaviour of the whole population (e.g. ant colonies).

Models based on matrix algebra are frequently used in ecology for modelling population dynamics, with the population disaggregated into age- or size-classes. Simile does have the ability to do matrix calculations with arrays but, as mentioned above, a more appropriate way of handling such problems is to view a class as being an object, and then specify that there are as many instances as there are classes. Class attributes, such as age-specific fecundity and mortality rates, can then be expressed as attributes of each instance.

"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.