Model design elements

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

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.