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

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.

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

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!

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.

 

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.

Discrete-event related elements

Event

Represents something that occurs instantaneously at various times. It can be triggered at a pre-defined time, or by other events occurring (possibly after a delay) or by the value of a system-dynamics element reaching a threshold. It has a value (magnitude) only at the points in time at which it occurs.

Squirt

Acts like a flow, moving substance into and/or out of compartments, but causes an instantaneous transfer as a result of events occurring rather than a steady flow.

Rule-based state variable

Has an equation for each event that influences it; when one of those events occurs, its new value is calculated from the corresponding equation. The value persists unchanged between occurrences.

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 "conveyor“ element, which stores values and reproduces them after a certain period of time. This can be done using a series of compartment-flow combinations or pairs 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.

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.

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.