Simile's visual modelling environment is based on the widely-used System Dynamics notation, involving the drawing of stock-and-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.

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.

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.

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.

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

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!

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.

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!

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.

Some other visual SD modelling packages, such as Stella, introduce new symbols which extend the SD 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.

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

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

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.

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.

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; polymorphism has no particular role to play in modelling.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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.

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:

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.

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:

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:

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.

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.