New features of Simile version 5.0
Getting started: how to build and run a simple model
Learn basic techniques for working with model diagrams, adding equations, running models and displaying the results
Introduction to compartments, flows, and the other elements used in model diagrams
Zooming; changing what is displayed; changing scale; printing
How to formulate equations; functions; sketched-graph and tabulated relationships
Types of submodel; saving submodels as models; loading submodels from file; plug-and-play modularity
Preparing a model for running; running the model; displaying results
Loading parameter values, time-series data and other values into a model at run time: the scenario file mechanism
Writing scripts to automate repetitive tasks or to batch model simulations
Opening and saving models, exporting model code and graphics
Load 2-dimensional parameter arrays from comma-separated grids, image files or other datafile formats
Saving raw data in scenario files
Keep all the parameter information in one place, and have models start up faster
Following influences round the diagram
Simile v5 makes it easy to show, and follow, the way information flows round the model
with_greatest(...) and with_least(...) functions
New functions allowing data from special submodel instances to be picked out
Get more accurate results more quickly in 'stiff system' problem domains
There are a lot of other improvements, most of which do not require the modeller to do anything differently; see What's new in Simile 5.0 and 5.1 for a more comprehensive list.
Happy modelling!
This Evaluation Edition of Simile has been specially developed for introducing new users to this award-winning software. It is limited to saving models of no more than 25 functions. You can build and run larger models, but you cannot save them. We hope this introduction to Simile will inspire you to upgrade to the Standard Edition. To upgrade, pleasevisit the web site of Simulistics, the developers of Simile.
This section takes you through the whole process of building and running a model as quickly as possible. The exercise is based on a simple model of a bank account, since we are all familiar with this context, and we can readily do the calculations ourselves. This should save you from thinking that there is something mysterious about how Simile calculates the behaviour of a model.
The model: a simple bank account model
Step 1: Starting Simile: what's on the screen
Step 2: Making the model diagram
Step 3: Adding initial values, parameter values and equations
Step 4: Initialising the model
Step 5: Choosing the output displays
We will make a model for a simple bank account, with interest paid annually at a rate of 10%, and $10 taken out every year. The account initially contains $300. This is what we expect to happen:
|
Opening balance |
$300.00 |
|||
|
Interest paid in |
$30.00 |
0.1 x 300 |
||
|
$10.00 |
||||
|
Closing balance |
$320.00 |
300 + 30 - 10 |
|
Opening balance |
$320.00 |
|||
|
Interest paid in |
$32.00 |
0.1 x 320 |
||
|
$10.00 |
||||
|
Closing balance |
$342.00 |
320 + 32 - 10 |
|
Opening balance |
$342.00 |
|||
|
Interest paid in |
$34.20 |
0.1 x 342 |
||
|
$10.00 |
||||
|
Closing balance |
$366.20 |
342 + 34.2 - 10 |
And so on. Note that the increments are getting bigger each year because each time the balance goes up, so the interest paid increases. The balance of the bank account is increasing at a faster and faster rate.
Having understood the calculations that we are going to perform, we now turn to the concepts needed to express these ideas in Simile.
We use a compartment to represent the amount of money held in the bank account, since this a quantity that changes incrementally over time. We use two flows, one to represent the gain of money from interest and the other to represent the loss of money by withdrawal. One flow (interest) will go into the compartment, while the other flow (withdrawal) will come out of the compartment. We will also use a variable to represent the interest rate (10%, or 0.1). This variable will be linked to the flow representing the payment of interest by an influence arrow, indicating that the amount of interest paid depends on the interest rate. Since the amount of interest paid also depends on the amount in the bank account, there we will also use an influence arrow from the compartment representing the bank account to this flow.
In this tutorial we want to introduce you mainly to the mechanics of working with Simile, and these are explained in detail in the following steps. The concepts involved in representing even a simple system like this one in a modelling language can be quite complex.
You start Simile by double-clicking on the desktop icon created during installation, or by clicking on the Simile icon in the Start Menu.
These are both shortcuts to the file <Simile Program Files>\System\bin\Simile.exe, where <Simile Program Files> is the directory you chose to install the program. By default, this is commonly "C:\Program Files\Simile50", though if you are using a network, it may be on a remote hard drive. If you would like to be able to start Simile from a different location, create a shortcut to this file.
Within a few seconds, the main window will be displayed.
When Simile starts, you see a single window. This contains:
We begin by drawing the model diagram for the bank account model. A note on colours used in the following description: when you add a component to the model diagram, it is initially drawn in blue. This means that the component is selected. You will see the ways in which this is useful later on. When the component is not selected, it will turn red. This is its usual colour, and means that the component needs some extra information (like a value or equation) before the model can be built.
You should see a box labelled comp1.






This completes the drawing of the model diagram. In the next step, you will provide the numeric values and equations you need for simulating the behaviour of the bank account. Note, however, that this sequence (complete the model diagram before providing any quantitative information) is followed here for convenience: in general, you are free to provide the quantitative information at any stage in the diagramming process.


![]()

Notice that every component of the model diagram is now black, rather than red as it was before. This indicates that every component has been mathematically specified, and so the model is ready for running: Simile has enough information to work out the flows, and thus to update the amount of money in your bank account forward through time.
This and subsequent steps assume that you are using the single-window Run-Time Environment. This is the default, so it is the one that you will be using if you have installed Simile and not changed your Preference settings. If the windows that appear when you come to run the model differ from the ones shown here, then please go to the "Edit" menu, select the "Preferences" item, and then select the "Use single-window Run-Time Environment" option.

Simile creates a new window: the execution window. This contains the controls for running the model; a list of the variables in the model; and an area where any of a variety of tools for showing model results can be displayed.

This is because we want to use a time step of 1 year rather than the default value of 0.1 years.
This is because we want to run the model for just 10 years at a time.

Note the graph window that appears. This is initially scaled with default values on both axes, but will rescale itself as needed. You can re-size the panel containing the graph by dragging on the little boxes on the horizontal and vertical panel separators.

Note the line that appears on the graph.
The simulation carries on for another 10 years.

The model will automatically rebuild, re-initialise and run again.
Either:
or:
Simile model diagrams are constructed from the following set of 11 symbols. The first four, the compartment, flow, variable and influence, are the fundamental elements of all System Dynamics models. All models will include one or more of these elements.
|
|
An amount of some substance |
|
|
|
A process moving a substance between compartments |
|
|
|
A constant or variable quantity |
|
|
|
Represents the fact that one quantity is used to calculate another |
Simile has a very rich concept: the submodel, which allows model elements to be grouped to represent an object or multiple objects. One chapter of the help is dedicated to the submodel concept. The following symbols are used in models involving submodels.
|
|
An envelope enclosing a group of model elements, collectively representing a class of object |
|
|
|
A process creating the initial number of instances of a population submodel |
|
|
|
A process creating new instances of a population submodel |
|
|
|
A process creating new instances of a population submodel for each existing instance |
|
|
|
A process destroying instances of a population submodel |
|
|
|
Represents the fact that one object is associated with another, with each playing a role in the association |
|
|
|
Represents the fact that an instance of a submodel can exist only under specific conditions |
|
|
|
Represents an iterative loop within a single time-step |
In : Contents
The compartment symbol is used to represent a quantitative state variable. Notionally, we think of a compartment as containing an amount of some substance, though it can be used in other situations where we want to represent the concept of state.
The informal interpretation of a compartment in System Dynamics modelling is that it represents a real, physical compartment that can contain some substance, just like a tank holds water. The compartment requires to be given an initial value - how much water does the tank hold at the start of the simulation? - and we need to construct flows in and out of the compartment so that the amount it holds can change over time.
This interpretation is fine to begin with, but must not be taken too literally. A compartment in System Dynamics modelling is, mathematically-speaking, a state variable: i.e. it is a variable whose behaviour is described by a differential (or difference) equation. And, unlike real, physical compartments, a compartment in System Dynamics:
In : Contents >> Model diagram elements
The flow arrow is used to specify a term contributing to the rate of change of a compartment. If the flow arrow enters a compartment, it specifies a positive contribution to the rate of change of that compartment. If it leaves the compartment, it specifies a negative contribution to the rate of change.
The information on the flows entering and leaving each compartment is used to calculate the net rate of change of the compartment. The net rate of change is the sum of all the inflow values minus the sum of all the outflow values. The net rate of change is in turn used to calculate the change in the value of the compartment.
In most respects, a flow is treated just like a variable. You can use the full range of the equation language when you enter an equation for the flow, just as you can do for a variable. You can have influence arrows going from it to other parts of the model, again just like a variable. The two differences are that:
In : Contents >> Model diagram elements
A variable is used to hold one or more values. The value or values come from a mathematical expression. The expression may simply be a number, or it may be a complex mathematical expression involving various variables, operators (such as + and -), functions (such as log or square root), and conditional elements. The value of a variable may vary during the course of a simulation, if it is calculated from other parts of the model that change over time, or it may be constant.
The term "variable" is used to refer to a specific type of model element. This single element can be used for a wide variety of purposes, each of which is referred to in a different way by some modellers. There is rich potential for confusion here, so the following table sets out the correspondence between how a Simile variable is used in a model, and how a modeller would interpret that use. (In case you are wondering why we don't have a number of model elements, one for each type of use: the answer is that this would lead to an unnecessary proliferation of element types. Also, you might wish to change the role of a variable as you build up a model, and you would not want to have to keep on deleting one symbol and replacing it by another.)
|
Modelling use |
Set-up of "variable" |
|
Parameter (a coefficient in an equation): e.g. the reproductive rate per individual animal. Could also be a site constant: e.g. elevation above sea level. Its value will remain constant throughout a simulation run. |
No influence arrows pointing to it. One or more influence arrows pointing from it. Value is a numeric constant or value is not supplied and "Fixed parameter" radio button is selected. |
|
Input lever: a slider control can be generated for each such variable, and the user can modify its value during the course of a simulation run by moving the slider left or right. |
No influence arrows pointing to it. One or more influence arrows pointing from it. Value is a numeric constant. "Variable parameter" radio button is selected. |
|
Exogenous variable: this is a variable whose value changes during a simulation run, and which influences the value of other variables, but which is not itself influenced by other variables. Typically used for climatic inputs, such as temperature or rainfall. |
No influence arrows pointing to it. One or more influence arrows pointing from it. Expression is some function of simulation time (i.e. involves the built-in function time). |
|
Intermediate variable |
One or more influence arrows pointing to it. One or more influence arrows pointing from it |
|
Output variable: typically, this is used to report on some aspect of model behaviour (e.g. the ratio of two compartments). |
One or more influence arrows point to it. No influence arrows pointing from it. |
|
Attribute of an object: there is only sense in doing this if the variable is inside a multiple-instance submodel, with different instances having different values. E.g. the x-coordinate or the species type of each of many trees. |
No influence arrows pointing to it. No influence arrows pointing from it. |
In : Contents >> Model diagram elements
To say that "A influences B" (i.e. to draw an influence arrow from A to B) means that A is used to calculate a value for B: in other words, the equation for calculating B will include A.
You can drag an influence arrow from and to most model elements. The exceptions and special cases are noted here below. Note that if you try to drag an influence arrow to a model element that cannot receive one, then it turns blue instead of green, and you will not be able to connect them together. You can store comments associated with an influence arrow by double-clicking the arrow.
In : Contents >> Model diagram elements
A submodel is first and foremost a way of grouping together a number of other 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. There are considerable benefits to using a single method to fulfil this range of needs, both in reducing what you need to learn, and keeping the resulting models simple and flexible.
This section overviews the different uses of the submodel construct, and the different types of submodel that you can have. Other sections provide more detail on particular topics.
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 a separate window for it (by double-clicking on its boundary with the
pointer). 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 the information about this interfacing can be stored in a file (an interface specification file). When you next load one of the submodels from a file, you simply refer to the interface specification file, and all the influence links are made in one quick operation.
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 (by going to 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: 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 … end if 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:
Let's say that you have a multiple-instance submodel containing information on the species and volume of a set of individual trees: each instance is one tree. You would like to find the total volume of all trees belong to species 1.
This is easy to do if you have model the trees using a fixed-membership submodel (i.e. assuming that you have a fixed number of trees). You simply take influence arrows from the species and volume variables inside the submodel to a variable outside (say total), and give total the equation:
total = sum(if [species]==1 then [volume] else 0)
[species] and [volume] are both arrays with the same number of elements, and Simile's array language matches them up.
However, if you use a population submodel to model the trees, then you have a problem. A population submodel exports a list of values rather than an array: it has to do this, because the number of values can change dynamically, rather than being fixed. Currently, Simile does not have a list-processing language corresponding to the array-processing language as above. All you can do with a list is to sum it, count the number of elements in it, or find it minimum or maximum value.
The satellite submodel is a mechanism for dealing with problems like this. In the above case, it would involve creating a new submodel for the species 1 trees, using a single role arrow from the tree submodel to this satellite submodel, and entering the condition "species==1". An instance of this submodel will be created for each tree of species 1, and not for the others. If you then take the "volume" value into the submodel, then you can extract the volumes just for species 1.
By default, Simile uses the same time step to update all the model state variables. However, if you are modelling a system containing trees and crops, then you might very well want to model the trees on an annual basis (time step of one year), and the growth of the crop on a weekly basis (time step of 1 week).
Simile enables you to specify a time step category for any submodel. For each new time step category that you request, Simile adds an extra Update every entry in the Run Control dialogue window, and that is where you specify the actual time step (e.g. 0.01) to be used for each category.
Complex models - that is, models with a large number of symbols and equations - can take a significant to build (i.e. generate the program for simulating the behaviour of the model). It can be as long as 10+ minutes for a complex model (100s of equations) on a slow computer.
Normally the build process is done with the whole model, and every time you make some change, no matter how small, it has to be done again before you can run the model. However, it is possible to specify that a submodel is built separately (in technical terms, a separate DLL is generated for it). This greatly speeds up the re-building process for any changes made to this submodel, since Simile has only to re-build the submodel, not the whole model.
In : Contents >> Model diagram elements
The Initialisation symbol is used to specify the initial number of individuals in a population submodel.
The Initialisation symbol only has meaning in the context of a population submodel. Therefore, it makes sense to construct a population submodel first, then add the Initialisation to it. This is not strictly necessary: you can add the Initialisation first, then construct a submodel around it, then make the submodel into a population submodel, but it is better practice to construct the population submodel first.
So, assuming that you already have a population submodel in your model diagram:
In : Contents >> Model diagram elements
The Migration symbol is used to specify the creation of new instances of a population submodel during the course of a simulation. In contrast to the Reproduction symbol, which specifies this in per instance terms (i.e. the creation of new instances per existing member of the population), the Migration symbol determines the total number of new instances that are created.
The migration symbol only has meaning in the context of a population submodel. Therefore, it makes sense to construct a population submodel first, then add the migration symbol to it. This is not strictly necessary: you can add the migration symbol first, then construct a submodel around it, then make the submodel into a population submodel, but it is better practice to construct the population submodel first.
So, assuming that you already have a population submodel in your model diagram:
The migration symbol it is used to determine the creation of new instances of a population submodel. This must be in terms of whole numbers: you cannot have a part of a new individual. And yet, the value for the migration term can be a floating-point number, e.g. 1.3. So how does Simile use this value to calculate the creation of new instances?
Three new instances are created every time step.
During the first time step, the value for migration (0.7) is not enough to create a new instance of the population submodel. Simile then remembers the value 0.7. When it comes to the next time step, the value for migration is then added on, giving 0.7+0.7=1.4. This is sufficient to create one new instance, leaving 0.4 in the bank.
The process continues, as shown here:
1 0.0 0.7 0.7 0 0.7
2 0.7 0.7 1.4 1 0.4
3 0.4 0.7 1.1 1 0.1
4 0.1 0.7 0.8 0 0.8
5 0.8 0.7 1.5 1 0.5
6 0.5 0.7 1.2 1 0.2
7 0.2 0.7 0.9 0 0.9
8 0.9 0.7 1.6 1 0.6
9 0.6 0.7 1.3 1 0.3
10 0.3 0.7 1.0 1 0.0
The value for migration is a migration rate, expressed in whatever your global unit of time is (typically 'year'). Therefore a value of migration of 0.7 individuals per year gives a value of 0.07 individuals in one time step (0.1 year). Exactly the same procedure as above is applied, with the migration value accumulating until a whole number of individuals can be created.
The same procedure as above is applied, with 3 new instances being created in some time steps, and 4 in others.
You might well feel uncomfortable with the deterministic nature of the process. In this case, it is up to you to engineer a suitable stochastic mechanism that generates new individuals at the same average rate. In the future, Simile will include functions for sampling from appropriate frequency distributions for handling a variety of options (please contact the authors of Simile if you want to discuss this). In the meantime, and if your rate of migration is less than 1, then you can treat the value as a probability that migration will occur, and use the following expression for migration:
if rand_var(0,1)<0.7 then 1 else 0
where 0.7 is the migration rate.
In : Contents >> Model diagram elements
The reproduction symbol is used to specify the rate of creation of new instances of a population submodel by each existing instance. It thus differs from the migration symbol, which specifies the total rate of creation of new instances.
The reproduction symbol only has meaning in the context of a population submodel. Therefore, it makes sense to construct a population submodel first, then add the reproduction symbol to it. This is not strictly necessary: you can add the reproduction symbol first, then construct a submodel around it, then make the submodel into a population submodel, but it is better practice to construct the population submodel first.
So, assuming that you already have a population submodel in your model diagram:
The reproduction symbol captures the concept that, in many biological situations, the production of new individuals by those already in the population - reproduction - is an important mechanism for increasing population size. Moreover, the ability of an individual to reproduce will depend on its own characteristics: its age or weight, for example.
As with the migration symbol, Simile needs to resolve the fact that the value for reproduction is a floating point number, while new individuals can only be created one-by-one. The method it uses to do this is similar to that used for migration, and essentially involves the use of the reproduction term to contribute fractions of an individual to an accumulator: when the accumulator exceeds a whole number, then that number of new instances for the submodel are created, and the accumulator is reduced by the number of instances created.
There is, however, an important issue that the designers of Simile had to address. Should there be one accumulator for the whole population, or one for each of the current set of instances? In the former case, if you had five instances, each with a reproduction value of 0.1, then one new individual would be created every 2 time units. In the latter case, for the same settings, you would get no new instances for ten time units, then five would be created at the same time. The first approach seems more attractive, but suffers from a fatal flaw: it assumes that the parentage of newly-created individuals is irrelevant. This severely restricts the modelling you can do: in particular, it rules out modelling evolution, since that requires some concept of (biological) inheritance, which in turn means that each individual needs to know who its parent(s) are. Also, the second approach gives the same behaviour as the first if the value for reproduction is treated stochastically (e.g. as a probability), rather than as a precise deterministic contribution until you have enough credit to make one individual. Therefore, in Simile, each individual accumulates its own credit until it has sufficient to make one new individual.
The following cases illustrate how Simile interprets the information provided in the reproduction symbol. In all cases, the analysis is for ONE INDIVIDUAL in the current population: the total input of new individuals into the population is the sum of the input from each individual.
Three new instances are created every time step.
During the first time step, the value for reproduction (0.7) is not enough to create a new instance of the population submodel. Simile then remembers the value 0.7. When it comes to the next time step, the value for reproduction is then added on, giving 0.7+0.7=1.4. This is sufficient to create one new instance, leaving 0.4 in credit. The process continues, as shown here:
1 0.0 0.7 0.7 0 0.7
2 0.7 0.7 1.4 1 0.4
3 0.4 0.7 1.1 1 0.1
4 0.1 0.7 0.8 0 0.8
5 0.8 0.7 1.5 1 0.5
6 0.5 0.7 1.2 1 0.2
7 0.2 0.7 0.9 0 0.9
8 0.9 0.7 1.6 1 0.6
9 0.6 0.7 1.3 1 0.3
10 0.3 0.7 1.0 1 0.0
The value for reproduction is a reproduction rate, expressed in whatever your global unit of time is (typically "year"). Therefore a value of reproduction of 0.7 individuals per year gives a value of 0.07 individuals in one time step (0.1 year). Exactly the same procedure as above is applied, with the reproduction value accumulating until a whole number of individuals can be created.
The same procedure as above is applied, with three new instances being created in some time steps, and four in others.
You might well feel uncomfortable with the deterministic nature of the process. In this case, it is up to you to engineer a suitable stochastic mechanism that generates new individuals at the same average rate. In the future, Simile will include functions for sampling from appropriate frequency distributions for handling a variety of options (please contact the authors of Simile if you want to discuss this). In the meantime, and if your rate of reproduction is less than 1, then you can treat the value as a probability that reproduction will occur, and use the following expression for reproduction:
if rand_var(0,1)<0.7 then 1 else 0
where 0.7 is the reproduction rate.
This may be a pretty reasonable way of representing things, if it is the case that some individuals produce 1 offspring, and others produce none, with a probability of 0.7 and 0.3 respectively. (Biologically, it is possible that some individuals may produce 2 or more offspring, with the average being 0.7. In that case, the above method is only a rough approximation, and you should aim to develop a solution based on the relative probability of different numbers of offspring.)
In : Contents >> Model diagram elements
The mortality symbol is used to specify the conditions under which one instance of a population submodel is destroyed.
The extermination symbol only has meaning in the context of a population submodel. Therefore, it makes sense to construct a population submodel first, then add the mortality symbol to it. This is not strictly necessary: you can add the mortality symbol first, then construct a submodel around it, then make the submodel into a population submodel, but it is better practice to construct the population submodel first.
So, assuming that you already have a population submodel in your model diagram:
In : Contents >> Model diagram elements
Role arrows join submodels that participate in some form of association, or where one is a satellite of the other. The following sections detail the mathematical methods invoked by the role arrow. In each case, a multi-dimensional matrix is created. The dimensions of the matrix depend on the number of role arrows used, and the different uses are therefore described in separate sections.
A role arrow can only be drawn between two submodels, one representing the object that plays a role in an association, and the other representing the association itself. Therefore, these two submodels must already exist in your model diagram.
In : Contents >> Model diagram elements
Using a single role arrow to connect two submodels is almost exactly equivalent to nesting one submodel inside the other. In effect, the submodel that the role arrow points to, is nested inside the submodel that the role arrow points from. This alternative diagram form is useful because of the extra flexibility it allows in laying out the model diagram. It is also helpful to understand this simple use of role arrows before using them in more complex ways.
The following model diagram illustrates the relevant features of the use of a single role arrow to connect two submodels. In this case, one submodel is called "Master", and the role arrow points from it, to the other submodel, called "Satellite". "Master" is a multiple-instance submodel, with fixed dimensions. In the following example, there are ten instances of "Master". Inside "Master" there is a variable called "index". The equation for "index" is "index(1)". The variable "index" therefore has a unique value within each instance of "Master".

To start with, consider that the
condition symbol in "Satellite" is omitted. In this case, ten instances of "Satellite" are created, the same as the number of instances of "Master". Inside "Satellite" is a variable called "var1". There is an influence arrow from the variable "index" in "Master" to "var1", and its equation is simply "index". The value of "var1" in each instance of Satellite is therefore equal to the "index" of the equivalent instance of "Master".
To illustrate how "var1" is treated, there are four influence arrows taken from it. Two influence arrows point to variables "count" and "sum" within "Master" and two point to variables "count" and "sum" outside "Master". There is an important difference in the values received in these two circumstances, which is easy to understand if you consider "Satellite" is treated as if it were nested inside "Master".
Beware one point: both inside and outside "Master", the value returned from "Satellite" is received as a list, which is not what would happen if "Satellite" were nested inside "Master". An integrating function such as sum() or count() must be used immediately on a list. Inside "Master", the list consists of a single number, so sum({var1}) returns the value of the number. The reason for using a list is that the list may in fact be empty, rather than containing a single value, for reasons described below. Note that curly braces are used to denote the list.
Now consider a simple equation for the condition symbol. In the example given, the condition symbol has no influence arrows pointing to it, though this is possible. Suppose one wishes "Satellite" to exist for only the odd-numbered instances of "Master". In this case, the equation "fmod(index(1),2)==1" would be used. Note that the index() function used within "Satellite" refers to the index of the equivalent instance of "Master".
Using the condition symbol in this or other ways permits the number of instances of "Satellite" to be less than the number of instances of "Master". There can never be more instances of "Satellite" however than instances of "Master".
In the example chosen above, in which only odd-numbered instances of "Satellite" are created, the four influence arrows behave like this.
When using the condition symbol in "Satellite", the use of the role arrow is more convenient than the equivalent nested arrangement. If "Satellite" were nested inside "Master" it would not be possible directly to receive the list in a variable outside "Master".
In : Contents >> Model diagram elements >> Role arrows
If a single role arrow between two models can be compared to nesting one submodel inside the other, using two role arrows to link submodels both to a third can be compared to creating an area where the two submodels overlap and are interleaved with each other. From the point-of-view of "Object A", "Object B" is nested within "Object A". From the point-of-view of "Object B", "Object A" is nested within "Object B".
The following model diagram illustrates some of the features of this arrangement. Two multiple-instance submodels are created, "Object A" with two instances, and "Object B" with three. Both these objects are linked with role arrows to the third submodel "Association". One instance of "Association" is automatically created for each possible pair of instances of "Object A" and "Object B".

In this case, there are six instances of "Association", resulting from the two "Object A" and the three "Object B". Inside "Association" is a variable "var1". The two variables that influence "var1" have the full path names "../Object A/index" and "../Object B/index". The instance of "Object A" and the instance of "Object B" from which each "index" is taken is determined by the instance of "Association". Each instance of "Association" receives one of the six possible pairs of the "index" variables.
Local names for the two different full path names are created to avoid duplication, and to avoid using illegal characters such as spaces in the equation. Change the local names to be "indexA" and "indexB" to avoid confusion. Right-click the parameter name to alter it, as described in the help page. In this simple example, the equation for "var1" is "indexA*indexB".
If this were represented by a table, it would look like this:
|
Object A - instance 1 indexA" = 1 |
Object A - instance 2 "indexA" = 2 |
|
|
Object B - instance 1 "indexB" = 1 |
Association - instance 1 "Var1" = 1 |
Association - instance 4 "Var1" = 2 |
|
Object B - instance 2 "indexB" = 2 |
Association - instance 2 "Var1" = 2 |
Association - instance 5 "Var1" = 4 |
|
Object B - instance 3 "indexB" = 3 |
Association - instance 3 "Var1" = 3 |
Association - instance 6 "Var1" = 6 |
The order of the instances in "Association" is determined by the order in which the role arrows are added. It is not usually important. To understand how "var1" is represented, six influence arrows are taken from "var1" to different parts of the model.
|
{var1} |
count({var1}) |
sum({var1}) |
|
|
Instance 1 |
{1 2 3} |
||
|
Instance 2 |
{2 4 6} |
|
{var1} |
count({var1}) |
sum({var1}) |
|
|
Instance 1 |
{1 2} |
||
|
Instance 2 |
{2 4} |
||
|
Instance 3 |
{3 6} |
To understand where both these sets of results for "{var1}" come from, look down (for "Object A") or across (for "Object B") the relevant lines of the full six instance "Association" table given above. The count() and sum() functions operate on the given {var1} to produce the results shown.
|
{var1} |
count({var1}) |
sum({var1}) |
|
|
{1 2 3 2 4 6} |
As with the use of a single role arrow, the
condition symbol will permit the number of instances of "Association" to be less than the product of the number of instances of "Object A" and "Object B". The Boolean expression used in the condition symbol can involve influences from other model elements and can use the index(x) function to return the instance of both "Object A" and "Object B", using x=1 and x=2 respectively.
In : Contents >> Model diagram elements >> Role arrows
The most common use of the role arrow is (unfortunately) the most difficult to visualise. In this case, two different instances of the same object play two different roles in an association. One might think of this as being like each instance having all the other instances nested within it.
In the case of the single role arrow, or the case of two role arrows from two objects, the role itself was not an important element. The role arrow represented graphically the nesting arrangement. In this case however, the names of the two different role arrows are the only means of distinguishing the instances of the single object within the association submodel.
The following model diagram illustrates a simple example of the use of the association submodel in this way. There is an "Object" submodel, which has three instances. Two role arrows, "Role I" and "Role II", link "Object" to the "Association" submodel.

In this case, nine instances of "Association" are created, one for each possible pair of instances of "Object". Inside "Association" are two variables "var1" and "var2". Each of these receives a single influence arrow from the "index" variable in "Object", BUT, look at the list of parameters in the equation dialogue box, and two are given. These two parameters refer to the "index" variable in each of the members of the pair of instances of "Object" that generate this instance of "Association".
A unique local name for each parameter is automatically generated, but to avoid confusion, right click on each local name to rename it indexI and indexII, for "Value(s) of ../Object/index (from Object in Role I)" and "Value(s) of ../Object/index (from Object in Role II)" respectively. In this example, "var1" is given the expression "indexI" and "var2" is given the expression "indexII".
If this were represented as a table, it would look like this:
|
Object in Role I "indexI" = 1 |
Object in Role I "indexI" = 2 |
Object in Role I "indexI" = 3 |
|
|
Object in Role II "indexII" = 1 |
var1 = 1 var2 = 1 |
var1 = 2 var2 = 1 |
var1 = 3 var2 = 1 |
|
Object in Role II "indexII" = 2 |
var1 = 1 var2 = 2 |
var1 = 2 var2 = 2 |
var1 = 3 var2 = 2 |
|
Object in Role II "indexII" = 3 |
var1 = 1 var2 = 3 |
var1 = 2 var2 = 3 |
var1 = 3 var2 = 3 |
So far, the results are rather similar to those where two objects are involved. This is also true of what follows, though it is less obvious. To understand how "var1" is represented, six influence arrows are drawn from it to different parts of the diagram. (Symmetrical results are generated using "var2", though these are not given here.)
|
Instance 1 |
{1 1 1} |
{1 2 3} |
||||
|
Instance 2 |
{2 2 2} |
{1 2 3} |
||||
|
Instance 3 |
{3 3 3} |
{1 2 3} |
||||
The
condition symbol can be used inside "Association" to permit fewer instances than the square of the number of instances of "Object" to be generated. The index(x) function returns the index of each of the members of the pair of instances that generate this instance of "Association" with x = 1 for "Dimension 1 of Object (3) in Role II for Association" and x = 2 for "Dimension 1 of Object (3) in Role I for Association". Note that the "(3)" is the size of the given dimension. Influences from other elements can also be used in the Boolean expression for the condition symbol.
In : Contents >> Model diagram elements >> Role arrows
A condition model element is used to specify whether a submodel, or a potential instance of a multiple-instance submodel, actually exists.
The condition symbol only has meaning inside a submodel. Therefore, you should make the submodel first, then add the condition symbol to it. This is not strictly necessary: you can add the condition symbol first, then construct a submodel around it, but it is better practice to construct the submodel first.
So, assuming that you already have the submodel that you wish to make conditional in your model diagram:
In : Contents >> Model diagram elements
An iteration model element makes its parent submodel an iterative submodel, whose contents should be evaluated repeatedly until a finishing condition is met.
The iteration symbol contains the condition that marks the successful convergence of the iteration. An influence arrow coming FROM the alarm symbol can be used as an argument to the function iterations( ). This function returns the number of iterations made so far. This function can be used to set the initial value (also called the guess) for the loop, i.e. when the number of iterations so far is equal to zero. If the number of iterations so far is one or more, then the result of the last calculation should be used. Since the last calculation depends on the result calculated from the guess, a circular loop of influences is present. Normally, Simile would reject this loop at build time, but setting a property of the influence arrow: "Use values made in same time step" to true, allows the loop to be processed. Influence arrows with this property set are drawn with a dashed line. To set this property for an influence arrow, double-click on it to invoke the property dialogue box.
In : Contents >> Model diagram elements
Working with the model diagram is the heart of the modelling process. The model diagram is a graphical representation of the all the elements and relationships within the system being modelled. Using the eleven model diagram elements, and the tools described here, an infinite range of models can be created. All work on the model diagram uses a selection mechanism to determine the elements affected.
|
|
|
|
|
|
|
|
There are four tools for manipulating the elements of the model diagram.
|
|
Selecting, in order to duplicate, move, delete or label elements |
|
|
|
||
|
|
||
The following tools are provided for convenience in working with model diagrams
|
|
|
|
|
|
|
|
|
|
|
The following advanced topics are dealt with separately.
In: Contents
The selection mechanism is straight-forward. First select one or more elements on the model diagram, then perform an action on the selection.
To select a single element, click on it using the pointer. To continue to select further elements, hold down the Ctrl key whilst clicking on them. If you select an element by mistake, click on it again with the Ctrl key held down, and it will be unselected, leaving the rest of the selection unchanged. To abandon a selection altogether, click in a blank area of the diagram. To select multiple elements at once, drag the pointer across the area containing them: a marquee (rectangular selection) will be drawn around the elements that are included in the area. The elements will all be selected when the drag is released. If any part of an element (excluding the caption) is included in the area, it will be included in the selection.
Various actions can be performed on selected element(s). The actions are available in the context menu, invoked with a right click. Once one or more elements are selected, the action chosen from the context menu will be performed on the selection, wherever the mouse is when the right-button is clicked.
The selection can be cut or copied to the clipboard. If you paste the clipboard into another program, such as Microsoft Word, a picture (metafile) will be shown in the document. If you paste the clipboard into Simile, the elements will be inserted, complete with functions and other properties.
The node-type elements are the
variable and the
compartment, as well as the elements used in population submodels. The following procedure is used to add node-type elements.
Note that the button you selected on the tool bar remains depressed until you select another button (i.e. to add a different element, or to change into a different mode, such as label or move). This allows you to add quickly several elements of the same type.
Note that it is not possible to add a node-type element to an area of your diagram that is already occupied. No error message appears, so if this happens, simply click somewhere else where there is sufficient space, or
move existing elements around to make sufficient space.
The arrow-type elements are the
influence,
flow and
role arrows. In general, arrows link two nodes, though there are exceptions, as explained below. There are two methods of adding arrow-type elements.
Alternatively,
Note that the button you selected on the tool bar remains depressed until you select another button (i.e. to add a different element, or to change into a different mode, such as label or move). This allows you to add quickly several elements of the same type.
A flow arrow must:
Note that if the flow arrow begins or ends in a blank area of the screen, Simile automatically adds the source/sink symbol (a cloud).
Note also that if you draw two flow arrows between the same two compartments in opposite directions, the arrows mainly lie on top of each other, but the valve (bow-tie) symbols are separated. You need to be careful that you know which valve symbol is associated with which arrow, when you come to add influence arrows or equations to the flows. You may like to use the
move tool to drag the ends of the flows around one of the compartments to separate them from one another.
An influence arrow must:
There is an exception to this rule. If you have an influence arrow coming from an input variable inside a submodel to some element (E1); then it is legal to draw an influence arrow from some other element (E2) to this influence arrow. The effect of this is to eliminate the input variable and to cause the influence arrow to go directly from E2 to E1.
Note that if you should accidentally miss the target model element, then the influence arrow will go shooting off to the edge of the model diagram window or submodel boundary. If that happens, then simply click on the
undo button in the toolbar, and try again. The reason for this behaviour is to allow you to add placeholders for influence arrows to be taken from submodels. Drag an influence arrow from the placeholder on the submodel boundary, to the desired element outside the submodel to complete the link.
Multiple influences coming from a variable in a submodel to variables outside it will share a common link as far as possible. This makes for a much neater diagram when there are lots of influences. However, this can cause odd behaviour when the influences point to variables on opposite sides of the submodel. You may find that one or more arrows leaving the submodel become detached from the point on the submodel boundary that the influence is attached to. You can usually fix this by selecting the
move tool from the toolbar, and dragging the attachment point around the submodel.
A role arrow must:
The following procedure is used to add a submodel to the model diagram.
Note that the submodel you make may or may not enclose existing model elements. When making a submodel, you can either make it to enclose some exi