Guided tour

In developing Simile, we have been guided first and foremost by our vision of what it is possible to achieve — what computer modelling within the research community could be like, given the right tools.

In particular, Simile has been developed in response to a wide range of serious problems with the current state of simulation modelling in the areas of earth, environmental and life science research. These problems result in the duplication of efforts between different research groups, and in a widespread perception of the failure of modelling to deliver on its promises as part of the scientific process.

Our approach is based on the principle of declarative modelling : that a model should be seen as being primarily a specification rather than as a piece of computer programming. Adoption of this principle makes many things possible that are simply not possible with the conventional, programming-based approach.

In Simile, we have implemented a number of key features to bring our vision to reality. Although we are still some way off achieving all the potential benefits of the declarative modeling approach, Simile does already address the problems we have identified with current modelling practice.

One key aspect is that we have achieved considerable generality in the types of models that can be constructed with a small number of model-design elements. These have a graphical representation in the model diagram, but also relate to the declarative specification of the model design.

One particular model-design element that gives Simile much of its power is the submodel. This enables the modeller to represent multiple objects, and to handle plug-and-play modularity.

Simile’s set of model-design elements make it possible for a wide range of modelling approaches, normally considered to be quite different types of model, to be supported within a single modelling environment. For example, one model may contain components that variously have characteristics of differential-equation, matrix-algebra, cellular-automaton and object-based models, all integrated in a single model.

Our vision

Imagine if...

 

  • you could build a model without having to learn programming, with no restrictions on what you could put into the model
  • models could be built in a fraction of the time currently required
  • you could run the same model on various platforms, even parallel computers
  • models could be seamlessly integrated with GIS
  • you could customise the types of displays used for visualising model behaviour
  • you could automatically generate a description for any model in a variety of formats and level of detail
  • you could share models with other people as easily as you can now share Word documents
  • you could search the internet for models just like you can now search for web pages
  • you could insert any model as a submodel in some larger model
  • you could download any model you wanted by clicking on a link in a web page
  • you could extract a submodel from a larger model, and run it as a stand-alone model
  •  

You can do all of these things with Simile, and more! And there's more to come...

  • you will be able to edit or run any model you find in your web browser
  • you will be able to query the structure of a model, just like you can query a database
  • you will be able to link model variables to data sets using metadata
  • you will be able to attach hyperlinks to any part of a model, taking a user to pages anywhere on the internet describing its biological or mathematical basis

Past problems

Simulation modelling is an important aspect of research in the earth, environmental and life sciences. Models can guide the research process; integrate the knowledge coming from a variety of studies; permit the testing of hypotheses; and enable predictions to be made. Many major research programmes have the development of such models as a central component of the whole programme.

In the recent past, most models are implemented in conventional programming languages, such as Fortran and C. We believe that in many cases this greatly reduces the effectiveness of the modelling effort. For example:

  1. It requires either that the researcher learns a programming language (which they may be unwilling or unable to do), or that a programmer is employed to implement the model (which is a significant cost and adds a barrier between the model as conceived and the model as implemented).
  2. Developing a reliable programmed implementation is a time-consuming hence costly operation, not only in the initial implementation of the model but also in its subsequent debugging and maintenance.
  3. It is difficult for others to fully understand the model, since they will be reluctant to wade through many lines of computer code.
  4. The written description of the model is often incomplete, sometimes ambiguous, and it has no guaranteed correspondence with the model as implemented.
  5. Shareability of model components with other researchers is severely limited, thus leading to considerable duplication of effort. This applies both to submodels and to support routines, such as data input facilities and tools for visualising model behaviour.
  6. Implementing model in a procedural programming language ignores the fact that running simulations is just one of the things we can do with a model: there are many other activities associated with the modelling process (such as comparing two models, generating descriptions of a model in a variety of formats, and transforming models) that could in principle be aided by a computer, but not if the model is implemented as a program.

These problems have been recognised for a good number of years in the modelling community, and various solutions have been proposed. First, there has been some development of modular modelling environments (such as APSIM), but these tend to make rigid assumptions about the way that submodels should integrate, and thus can at best only work within a small, well-defined community. Second, there are now a number of simulation languages (such as ACSL), and visual modelling environments (such as Stella, ModelMaker and PowerSim). These certainly reduce the programming overhead, but tend to restrict the modeller to a certain modelling approach (such as differential equations or System Dynamics modelling). Third, there is now considerable interest in the adoption of object-oriented or component-based technologies such as C++ or COM. These have the potential to permit re-use of model components between groups, but are still tied into a programming paradigm for the implementation of the individual model components.

Declarative modelling

Simile is billed as a “visual modelling environment”, meaning that models are developed diagrammatically (as opposed to writing lines of text, as in a programming language or a simulation language). However, a more fundamental feature of Simile is that it is a declarative modelling environment. In a sense, Simile’s visual modelling interface is just one way of building a Simile model: we could envisage other interfaces (such as a text editor) that would still produce a Simile model, but would not be visual.

What do we mean by “declarative modelling”? First, we note that the term contrasts with a procedural approach, which is what we do when we implement a model in a conventional (procedural) programming language, such as Fortran or C. In that case the lines in the program are in fact instructions to the computer: calculate this value, loop over the array elements, print the value for this variable. Some of the lines might look exactly like declaratively-expressed equations, but they are in fact assignment statements. Thus, without the use of strictly-observed (and arbitrary) conventions, we cannot really distinguish between the assignment statements in the program that constitute the model equations, and all the other assignments we might have in the program. Effectively, we can do only two things with the program: run it (to calculate the values for the model variables); or show it to a human who understands the programming language. And running it is the only thing that a computer can do for us.

In declarative modelling, we represent a model not as a series of assignment and control statements, but as a set of facts that are true about the model. The order in which we present the facts is (unlike a procedural program) irrelevant. The full set of facts defining a model actually constitute a specification for the model: given these facts, and knowledge about what the symbols mean, someone else can construct a working version of the models.

A good example is in architectural design. We would never dream of specifying a Architectural blueprint design for a building in a computer program: rather, we would express it as a set of facts, defining the walls, doors etc, and their size, location and materials. Given this information, we could draw a plan for the building. We also have all the information we need to do calculations about the building: how big it is; how quickly it would heat up and cool down. The program that does the calculations is indeed procedural; but the design of a particular building is held as a set of facts.

And so it can be with models. A model is a certainly a design, expressed in terms of the constituent parts of the model and the linkages between them. It can certainly be expressed declaratively: look at he “Model description” part of any modelling paper. The declarative statement of model structure is sufficient to enable someone else to make a runnable version of the model, provided that it is complete, unambiguous, and that the meaning of the terms used is understood.

There are significant advantages in adopting an declarative approach.

First, there is no risk of the description of the model failing to match the implementation of the model: the description is the implementation.

Second, once a model is represented declaratively, one can do many things with it as well as just simulating its behaviour: for example, generate descriptions in a variety of formats, interrogate its structure, compare it structure with that of another model, or transform it into a simpler or more complex model.

 Third, one can generate runnable versions of the model in a variety of languages (including languages for parallel computers): you are not limited to one that the model happens to be written in. Finally, the adoption of a declarative modelling approach encourages the development of common standards for representing models, the distributed development of modelling tools, and the sustainability of the effort put into developing models.

 Simile, in common with other modelling environments, necessarily adopts a declarative approach: it is hard to build up a representation of the model during the design process without doing this. However, in developing Simile we have also committed ourselves to the idea that the language for representing the model structure should be open, so that any other person or group can develop their own tools for processing Simile models — including tools for generating runnable versions of a model or indeed model-design environments.

Features

Ease of use

Simile’s visual modelling environment is based on the familiar System Dynamics notation, involving the drawing of flow and influence diagrams. Both concepts are intuitive, and thus readily learnt. Simile adds on to this a concept of objects, which are simply submodel boxes drawn around other model elements and given the property of having multiple instances. These can be nested to show the notion of containership in an obvious manner.

Simile’s ease of use reduces the barrier for researchers to get on with modelling. Whether they wish to implement a published model, work with a Simile model provided by a colleague, or develop new models from scratch, the learning effort is much less compared with programming, and the time required to produce models greatly reduced even for the competent programmer.

Simile’s ease of use also makes it very suitable for teaching. Even if your aim is simply to give the students a pre-built model, it is beneficial for them to see this as the model diagram, rather than being given separate documentation for a black-box programmed model. Simile has been used successfully in class model-design exercises, with groups working on submodels which are then combined to make the whole model.

Smooths the transition from conceptual to mathematical modelling

Modelling is not just about producing results through running a simulation model. It is a social activity, involving many people (other researchers, managers, local people) who are able to contribute to the formulation of a model, but who have no wish to model themselves. Because of Simile’s intuitive interface, including familiar, every-day concepts such as stock, flow, influence and object, many people are able to contribute to the model-design process; while the modeller knows that the result of the conceptual-modelling phase can be gradually fleshed out to produce a fully-defined model.

Expresses a wide range of modelling concepts

Many models are developed within a particular modelling paradigm (using the term paradigm in the dictionary sense of “a conceptual framework within which scientific theories are developed”). Thus, a particular model might be described as differential equation model, a System Dynamics model, an age-class model, a spatial model, a cellular automaton model, an object-oriented model, or an agent-based model. Some large-scale ecosystem models do combine two or more paradigms, but these tend to be implemented as large, unwieldy programs.

One of the strands that led to the development of Simile was to explore the extent to which all (or as many as possible) modelling paradigms could be handled within a single, easy-to-use visual modelling environment. This does not mean that each one has its own identity within Simile. Rather, it means that each one can be readily recast to fit within Simile’s model-design language. To a large extent, this is now possible: one model can have parts that are simple System Dynamics, other parts which are disaggregated into spatial elements or age-classes, and other parts that involve dynamically-varying populations of objects — all interacting with each other. The section on modelling approaches discusses these in detail.

Nevertheless, we are not claiming that Simile can handle all modelling paradigms. Areas that we wish to develop in the future include qualitative and rule-based modelling, multi-agent system modelling, and certain forms of within-model optimisation.

Handles large and complex models

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.

Generates computationally-efficient models

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.

Supports modular modelling

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. At the other extreme, you can simply load a submodel, then edit it and use influence arrows to link between variables in the submodel and those in the main model. This enables you to make use of other people’s (sub)models, even if they were not originally intended for use in your model.

Simile also supports “unplug-and-play”: the ability to extract a submodel from a model and run it as a stand-alone model. All inputs that previously came from the main model now appear as user-specified input values. This is extremely useful for checking out the components of a complex model.

Supports user-developed run-time input/output tools

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.

All the input/output tools supplied with Simile are Tcl/Tk programs stored as text files in one subdirectory in the main Simile directory. Simile builds up a list of the available tools each time you start it up. Any user of Simile, with access to someone who is prepared to program in Tcl/Tk, can add their own files to this subdirectory, either by copying and modifying the existing ones, or writing new ones from scratch. You can thus provide displays specific to the type of system you are modelling and your own display needs. Having done this, you can then share them with the Simile community. Thus, the whole community can contribute to Simile development!

Generates models that can be interfaced to other software systems

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.

Open format for saved models

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. This reflects our commitment to open modelling standards, with a variety of tools, produced by many different groups, for processing models in a variety of ways. Indeed, there is no reason why some other group shouldn’t set out to produce a visual modelling environment that competes with, or complements, Simile itself!

Model design elements

This section lists the model-design elements that you can use to construct a model in Simile. These are described in terms of their graphical representation: i.e. the symbols you place on the model diagram as you build up the model design. However, you should appreciate that the diagram is really just a way of visualising the internal state of the model specification, there being a one-to-one correspondence between a graphical symbol and a statement in the internal model specification. In principle, one could build a model purely in textual terms, by entering the set of statements defining a model directly, rather than going through the diagrammatic interface.

 

Model diagram elements

System Dynamics elements

 

Compartment

We can think of a compartment as representing the amount of some substance, hence the use of other terms in the System Dynamics community, such as stock or level. Mathematically, a compartment represents a state variable whose behaviour is defined by a differential equation. A compartment requires an initial value, which is usually a numeric constant, but can be calculated from other constants.

Flow arrow

A flow represents a process causing an increase or decrease in the amount of substance in a compartment. It is thus represented visually by an arrow pointing into or out of a compartment, possibly connecting two compartments. Mathematically, a flow is an additive term in a differential equation for the associated compartment (state variable). The value assigned to a flow can be a constant or a function of other quantities in the model.

Variable

A variable represents any quantity whose value is either a constant or calculated as a function of other quantities in the model. In modelling terms, a Simile variable can thus represent a parameter, an intermediate variable, an output variable, or an exogenous variable.

Influence arrow

An influence arrow represents the fact that one quantity is used to calculate another.

Object related elements

 

Submodel

In Simile, a submodel is a round-cornered box that encloses a number of model-design symbols, including possibly other submodels. In modelling terms, the single concept has a range of interpretations, ranging from a purely visual dividing up of a complex model into its component parts (e.g. “the soil water submodel”), through the defining of objects in the model (such as individual trees or animals), to defining an association between objects (such as an ownership association between farmers and fields). Because the submodel concept is so central to Simile, has so many uses, and sets it apart from more standard approaches, the next section considers submodels in more detail.

Condition

A condition element is placed inside a submodel to indicate that the existence of the submodel depends on some condition. For example, we might have a model with multiple patches of land, of which only some have a crop. In this case, we would have a crop submodel inside the (multiple-instance) patch submodel, with the crop submodel being conditional on the landuse for this patch being of type “crop”.

Role arrow

Role arrows are usually used in pairs, with each arrow going from a submodel to a submodel. The combination of submodels and role arrows is used to denote an association between the objects represented by the submodels at the start of each role arrow. The term “association” refers to a relationship such as the neighbour relationship between two patches of land, or an ownership relationship between farmers and fields.

Initial-number

The initial-number element is used to specify the initial number of members in a population of objects.

Migration

The migration element is used to specify the rate at which new members of a population are created.

Reproduction

The reproduction element is used to specify the rate at which each member of a population creates new members.

Extermination

The extermination element is used to specify the rule for killing off a member of a population of objects.

 

Discussion

The above set of model-design elements reflects the choices made by the Simile design team. In some cases (such as the System Dynamics elements of compartment and flow) there was in fact little choice, given the wide-spread acceptance of this diagrammatic notation in the research community. In other cases, we have invented elements that we saw as being required to meet a certain modelling need.

This set is almost certainly minimal: it is hard to see how the number of elements could be reduced further, without making it impossible to express certain modelling concepts. Conversely, it is very easy to propose new elements which are not strictly necessary (i.e. their function could be replicated by some combination of existing elements) but which might simplify the model diagram or enhance its readability. One example is the introduction of a “memory“ element, which stores a value until it gets a signal to change it. This can be done using a compartment-flow combination or a pair of variables linked by the last( ) function, but neither of these is a clean way of diagramming the basic concept. The problem is that, once you start going down this route, then there is the risk of a rapid explosion in the number of symbols available to the modeller, and one has to trade off the advantages of having more symbols against the increased learning required to read a diagram.

We do not claim that the set of model elements that we have come up with in Simile is optimal. However, in designing Simile, we have become very aware of the issues involved in designing the elements for a modelling language, and of the trade-offs involved between having a small number of more abstract elements versus a larger number of more concrete elements. These issues and trade-offs need to be given careful consideration in any attempt to design a generic modelling environment.

Using submodels

A submodel in Simile is a way of bundling up a number of model elements, including other submodels. This is done by either drawing a submodel envelope around a number of elements in the model diagram, or by creating an empty submodel and inserting model elements into it.

However, the reasons for wanting to do this are many and varied, and it is important to appreciate that the submodel construct can be used for a range of modelling needs. These are normally considered as being pretty separate, so it may come as some surprise to see that the same model-diagram construct can be used for these different purposes. However, there are considerable benefits by using a single method, both in terms of what you need to learn, and in terms of the machinery that lies inside Simile.

This section overviews the different uses of the submodel construct, and the different types of submodel that you can have.

Using a submodel to show the main components of a complex model

You have constructed a model with a number of compartments and flows. Some relate to vegetation; some to the animals in the area; some to soil water and nutrients. By grouping the model-diagram elements for these different parts into submodels (called “Vegetation”, “Animals” and “Soil”), the gross structure of the model is immediately apparent.

Conversely, you may prefer to design a model in a top-down fashion. Starting with a blank screen, you can rapidly add submodels corresponding to the main components of a proposed model, then subsequently add the various compartments, flows etc inside these.

Using a submodel for multiple views on a model

Once part of a model is made into a submodel, you can open up a separate window for it (by double-clicking on its boundary). This window can be kept on the screen while you scroll the main model diagram to some other part of the model. Also, you can change the zoom factor for each main model window or submodel window separately, enabling you to see part of the model in fine detail while maintaining an overview of the whole model at a coarser scale.

Using a submodel to extract a part of a model

For the model described above, you may want to see how the vegetation part behaves, assuming fixed inputs from the animal and soil sections that affect it. You draw a submodel envelope around the vegetation, open up a separate window for it, then use the File: Save command to save it to a file. You can then start up Simile again, and load just the saved vegetation submodel (which is now a model in its own right). You can now explore how it behaves by itself. This can be very useful for testing and debugging purposes.

Using a submodel for modular modelling

For many years, the battle cry of those fed up with the implementation of models in computer programs was modular modelling. If we had a modular modelling system, it was argued, then models could be easily constructed from a number of pre-programmed modules, and the effectiveness of the community as a whole would be greatly increased by the sharing of these modules, avoiding huge duplications of effort.

The submodel concept in Simile supports modular modelling. You can open up a separate window for a submodel (say, a vegetation submodel); clear the contents of the submodel (by doing File: New), then load a different vegetation model into the submodel window. Influence links with the rest of the model can then be made one by one.

Furthermore, Simile supports “plug-and-play” modularity (which is what is normally meant by “modular modelling”). If two or more vegetation submodels have been designed to share a common set of influences (in and out) with the rest of the model, then Simile the information about this interfacing to be stored in a file (an interface spec file). When you next load one of the submodels from a file, you simply refer to the interface spec file, and all the influence links are made in one quick operation.

Using a submodel for disaggregation; or (conversely) specifying a fixed number of objects of a certain class

These two terms are lumped together because they are the same concept, seen from opposite perspectives. You can disaggregate an area into a number of patches; or you can think in terms of one patch, then have multiple patches to represent some larger area. The end result in both cases is exactly the same.

Once you have made a submodel you can specify (in its properties dialogue box) that it is a “fixed-membership submodel”, and specify a number of instances. The submodel then represents each of that number of instances. Visually, it now appears different, because it now has multiple lines on the left and bottom edges (rather like a stack of cards). Internally, Simile now handles each instance separately: each can have its own parameter and initial values, while they all have the same compartments, flows etc.

This enables many forms of disaggregation to be captured. For example:

  • disaggregating a population into age, size, or sex classes;
  • disaggregating a vegetation component into the several species that make it up;
  • disaggregating soil or forest canopy into a number of layers;
  • disaggregating space into grid squares, polygons, or some other form of spatial unit.

Using a submodel to specify a dynamically-varying population of objects

The modelling world divides into those whose models are based on differential/difference equations (with or without disaggregation); and those who subscribe to an approach based on collections of objects (variously called object-oriented, individual-based or agent-based modelling).

Simile enables a population approach to be combined with a differential-difference equation approach. For example, a modeller might represent the vegetation in terms of compartments and flows, while the herbivores might be represented as individual animals, which are created, grow and die. In order to do this, a submodel is specified as being a population submodel (again, in its properties dialogue box), and model elements can be added for specifying the initial number, and the rules for the creation of new individuals and the elimination of those already n the population. Visually, the submodel now appears with a shadow line for the top and left edges, and another for the bottom and right edges.

Using a submodel to specify the conditional existence of some part of the model

When a model is implemented in a conventional programming language, large chunks of the program can be enclosed inside an if...endif block: i.e. whether it is actually evaluated depends on some condition. This programming device may be applied to several different purposes:

  • You may want to have several alternative ways of modelling some part of the system (e.g. a growth function), only one of which is active in any one run of the model. A flag determines which one is active.
  • You may want to model a set of species using a single submodel, but with only some species present in any one run of the model.
  • You may want to model a number of spatial patches, some of which contain one land use type, and others of which contain another. You need to include a submodel for each one within the multiple-instance patch submodel - but switch one or the other on in a particular patch.

All these situations can be handled in Simile using a conditional submodel. This is simply a normal submodel, but with a condition symbol added. Visually, we can tell that it’s a conditional submodel both by the presence of the condition symbol, and by a set of dots going down diagonally to the right from the submodel envelope. The condition contains a boolean expression: if this evaluates to true, then the submodel (or an instance of it) exists; if not, then it doesn’t.

A conditional submodel will, like any other, have influences coming out from the model elements it contains. However, the number of values passed along each influence will either be zero (if the submodel does not exist), or one, if it does. This is thus a variable-size data structure: in other words, a list (with the name of the variable enclosed in curly braces {...} ). In Simile, the only thing that can be done with a list is to evaluate it: usually, to sum its values. If the list is empty, then the sum is zero. If the list contains a single element, then the sum is whatever this value is.

Using a submodel to specify an association between objects

Once our modelling language allows us to think in terms of multiple objects of a certain type, then it is frequently the case that we start to recognise relationships between objects. These relationships may be:

  • between objects of the same type: one tree shades another; one grid square is next to another; one person is married to another; or
  • between objects of one type and objects of another: one farmer owns a field; one field is close to a village.

Since Simile is a visual modelling language, and since such relationships are an important aspect of the design of a particular model, Simile provides visual elements to show diagramatically such relationships between objects. Unfortunately, the term “relationship” is normally used in ecological modelling to refer to a relationship between variables (as opposed to objects), so we use the term “association” instead. This is the same term used in UML (the Unified Modelling Language, the standard object-oriented design language used in the software-engineering community).

An association can itself have properties. We can, for example, have a variable representing the actual distance between a field and a village: this is a property of neither the field or the village, but of the association between them. In Simile, the submodel is the construct that is able to hold a number of quantities, therefore we use a submodel to represent an association: it is then called an association submodel.

However, such a submodel is simply a normal Simile submodel. It becomes an association submodel by virtue of being linked to the submodel (or submodels) representing the objects that have the association. The linking is done using role arrows: one role arrow is drawn for each type of object that participates in the association. Thus:

  • for the owns association between farmer and field, we draw a single role arrow from the farmer submodel to the owns association submodel, and one from the field submodel to the owns association submodel;
  • for the next to association between one grid square and another, we draw two role arrows from the grid square submodel to the next to association submodel: one role arrow represents the field under consideration, while the other represents its neighbour.

Using a submodel to specify a “satellite” relationship

When you pass information out of fixed-membership multiple-instance submodel, it appears as an array with a fixed number of elements. You can extract the value for any one element using the element([array],index) function, and the element you extract will correspond to the instance in the fixed-membership submodel. This makes it possible to select values for one variable on the basis of the value for some other variable.

However, when you pass information out of a population submodel or an association submodel, all you get is a list of values: each value is not tagged with the index (instance number) of the submodel instance that produced it. Thus, if you had a population submodel for a population of rabbits, and you wanted to find the total weight of all rabbits over two years in age, you couldn’t do it simply by looking at a list or lists coming out of the submodel.

The satellite submodel is a way of making this possible. It is a submodel with a single role arrow pointing at it (in contrast with an association submodel, which has two role arrows). At most there will be one instance of this submodel for every instance of the parent submodel (the one the role arrow comes from). But, as with a conditional or an association submodel, you can place a condition model element (the question mark symbol) inside it, and this can limit the number of instances to be some subset of the maximum number possible. The condition you insert is then specified to restrict the subset to that which you require.

Using a submodel to specify different time bases for different parts of a model

By default, all parts of your model tick at the same rate, as specified by the Update every... value in the run control dialogue window. However, you will sometimes want to get parts of the model updated less (or more) frequently than others. For example, you may have a model containing both trees and a crop. The crop you want to grow on a weekly basis, so you can capture its response to rainfall patterns, pest outbreaks etc. The trees grow slowly, and there is no point at all in calculating tiny increments on a week-by-week basis. Conversely, your model may include a fire spread submodel, which is triggered only very occasionally but then needs to simulate the spread of fire at very short time steps.

In order to specify this, you need to ensure that the component of the model with a separate time base is in a separate submodel. You then specify the time base for this submodel (and, by default, any inside it) in the submodel properties box.

When you come to run the model, Simile then realises that there is more than one time base for the model, and adds one or more extra Update every... in the run control dialogue window. The user of the model then needs to specify each one separately, in terms of the model’s unit of time. In the above example, the value 1 (year) and 0.02 (years, equals roughly 1 week) could be specified for the two Update every... values.

Modelling approaches

Modellers frequently classify their model as being one type or another: “differential equation model”, “matrix model”, “individual-based model”, and so on. Simile is capable of handling most of these model types — sometimes directly, sometimes with some recasting. The aim of this section is to consider some of the more common model types, and how they are handled in Simile. It should be remembered, however, that a model in Simile can combine what would normally be considered distinct and non-combinable modelling approaches. Thus, in Simile, it is quite possible to have a model that combines, for example, differential-equation, matrix, and individual-based modelling.

 

System Dynamics

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 System Dynamics models in Simile.

Some other visual System Dynamics modelling packages, such as Stella, introduce new symbols which extend the System Dynamics language (such as “oven” and “boxcar”). Simile does not have these, but their behaviour can be reproduced using Simile’s core set of model-building elements.

Differential/difference equation models

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). Therefore, implementing a published differential-equation model in Simile is straightforward: you simply add one compartment for every state variable, give each compartment a single inflow, and enter the differential equation as the flow expression, having first added the required influence arrows.

Since Simile can use simple Euler integration for numerically solving its set of differential equations, handling sets of difference equations is no different: the only difference is when you come to run the model, when you set the time step to 1 rather than some small value.

Discrete event models

In a discrete-event simulation, all change occurs at instants in time, rather than over periods. The fundamental components are states and events. States can change as a result of events, and events can occur at pre-set times or be triggered by other events, conditionally on states, possibly after a delay.

Pure discrete-event models do not need a regular time step. Instead, the time of the next event can be calculated after each event, and the simulation jumps directly to that time. Typical domains for discrete event simulation include network, traffic and queueing systems.

Simile can run pure discrete-event models, but allows their components to be mixed with system dynamics components to build hybrid models. Obviously values can be passed between states and system-dynamics components, but there are special constructs for integrating events themselves with system dynamics:

  • The limit event, triggered when the value of an equation including dynamic values reaches a threshold
  • The squirt, allowing an event to instantaneously change the level of a compartment.

An example of a simple system requiring hybrid modelling is a bouncing ball. While the ball is flying, its behaviour is governed by continuous processes modelled with system dynamics, but bouncing is an event involving instantaneous change, and calculating the time of the bounce involves a continuously varying quantity reaching a limit.

 

Disaggregated models

“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. It is a very common and important modelling technique, required to capture dynamics that would be lost in a lumped model of the same system.

In conventional programming and in the other visual modelling packages, disaggregation is handled by declaring certain variables to be arrays rather than scalars (single-valued variables). This is a tedious approach, reflecting the design approach of the earlier programming languages (Fortran, BASIC), which is difficult to read visually.

Simile encourages a quite different approach. You use a submodel to represent one of the disaggregated elements: a single soil layer, a single population class, a single subarea, or a single vegetation species. This submodel is then made into a multiple-instance submodel, so that it now represents all the soil layers, all the population classes, etc. Finally, you add the links that relate one element to the next: e.g. the flow of water from one layer to the next.

Matrix models

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.

Individual-based models

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

If you have a fixed number of individuals, then you can use Simile’s fixed-membership submodel. If, as is likely to be the case, the number of individuals in the population changes dynamically, then you would use Simile’s population submodel, adding the three symbols needed to specify the initial number of individuals in the population, the way in which new individuals are created, and the way in which individuals are killed off.

Object-oriented models

The term “object-oriented” has a formal meaning in software engineering: it is not just “modelling with objects” in the sense of individual-based modelling. Rather, it reflects a commitment to a number of principles which together characterise the object-oriented approach, including message-passing, encapsulation (hiding internal detail), inheritance (from class to subclass), and polymorphism (the same procedure can operate on different data types). There is a strong movement towards the adoption of object-oriented software engineering approaches in ecological modelling.

It may come as some surprise, therefore, that not only does Simile not incorporate most of the characteristic features of the object-oriented approach, but that we have deliberately decided not to incorporate them. This is a controversial area, which we won’t develop here. But briefly:

  • the message-passing paradigm is inappropriate for systems based on differential/difference equations;
  • encapsulation is just what modellers does not want: they should have access to any attributes of any object;
  • inheritance, and a class hierarchy, can rapidly become extremely messy when the class is a designed model, and the subclass is some modification of this design;

Rejecting encapsulation does not mean that we are against modularity or re-use of components: quite the opposite. We are just against the principle that you really should not know what is inside a modelled component.

Simile does, however, support certain object-oriented design concepts. A Simile diagram with submodels corresponds closely to a UML class diagram. The Simile notation of placing one submodel inside another to indicate containership corresponds closely to a composition association. And Simile provides explicit notation for an association between classes.

Spatial models

The term “spatial modelling” refers to a particular form of disaggregation, in which an area is divided into a number (often a large number) of similar units: typically grid squares or polygons. The model may be linked to a GIS for data input and display. The transition from non-spatial to spatial modelling is often considered to be pretty significant, and there are a number of modelling packages that advertise their spatial modelling capabilities: indeed, many are labelled as landscape or landuse modelling tools.

Simile is rather odd in that it can do spatial modelling — in fact, it can do it rather well — while having no explicit spatial modelling constructs! All you need to use are the standard Simile model-design elements. It is only the use of maps for displaying model results (and potentially inputting information into the model) that reveal that it is a spatial model - and all the Simile input/output tools (helpers) are quite independent of the basic simulation engine.

In Simile, a spatial unit is just like any other unit. You define a single instance in a submodel, and then specify that you have many instances. The only difference now is that each instance will have two attributes specifying its x and y coordinates. These enable any display tool to locate each unit in the appropriate part of the display (map). They may also be used in spatial reasoning within the model: e.g. for working out the distance between two spatial units to calculate seed dispersal or shading.

The model itself does not “know” if a spatial unit is a square, a polygon, a hexagon or whatever (in fact, it does not even know that it contains spatial units). It is up to the modeller to model each type in a way which is consistent with what is intended. Thus, if the units are grid squares, then they should all have the same value for an “area” attribute, and the rule for defining which units are neighbours of which other units can be defined in terms of the column and row attributes. If they are polygons, then both the area of each unit and its neighbours will (typically) be defined in a data file. And in either case, the user of the model would need to choose a display tool that is appropriate to the type of unit being modelled.

As of version 6.1, we did introduce pre-defined array types for rectangular and hexagonal grids. Such grids are a very common methodology in ecological modelling, and it makes more sense to allow a modeller to select a pre-defined type and thus get access to functions providing each grid square instance with values from particular neighbouring grid squares, than have to figure out how to create a neighbour relationship to provide access to these values. We would hope that this feature encourages modellers to experiment, and perhaps lead on to use of the full power of the association submodel methodology.

Modular models

The term “modular modelling” usually refers to the use of interchangeable components (or modules) in a model. The component may be a single equation, but typically it is a large component: for example, a plant submodel or a soil water submodel. There have been calls for the development of modular modelling approaches for some two decades, and some working systems, motivated by the advantages that this would confer on the modelling process in terms of model construction, testing and reuseability of components. In addition, a major motive for the adoption of object-oriented software engineering approaches has been its support for modularity in modelling.

The purest form is “plug-and-play” modularity, in which the interfacing between a module and the main model is pre-defined (like the pins on an integrated circuit chip). All the modeller needs to do is to load the module, and it is automatically part of the model. Simile enables you to do this, as a two-step operation. First, you load the module (a Simile model, loaded into a submodel window). Then you select an Interface Specification File which defines the links between the submodel and the rest of the model. This approach has considerable merits: it means that the same Simile model can be inserted as a module in a range of other models, with different interfacing for each one.

At the other extreme, Simile supports “free-form” modularity, in which it is entirely up to the modeller to decide how the inserted submodel links to the rest of the model. This means that the modeller has access to a much greater range of models to use as submodels — ones that were developed with no intention that they be used as a submodel in someone else’s model. This removes the need for careful defining of interfaces which plagues current modular (and indeed object-oriented) systems.

Population dynamics models

You will probably by now appreciate that you have a variety of options when it comes to modelling population dynamics. You can adopt a lumped approach in System Dynamics, using a compartment to represent population size, and flows to represent demographic processes of reproduction, migration and mortality. Or, you can adopt a disaggregated System Dynamics approach, using a compartment-flow structure to represent the dynamics of one age/size/sex class, embedded in a multiple-instance submodel to represent all the classes. In this case, you will need to have additional flows for modelling the movement of individuals between age or size classes. Or you use a population submodel to represent every individual in the population, adding in rules for specifying the creation of new individuals and the death of existing ones. In this case, it is optional whether your model contains any System Dynamics at all: you might decide to use a compartment-flow structure to represent, for example, the body weight of each individual, but you certainly don’t have to.