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.
Modelling is not just about producing results through running a simulation model. It is a social activity, involving many people (other researchers, managers, local people) who are able to contribute to the formulation of a model, but who have no wish to model themselves. Because of Simile’s intuitive interface, including familiar, every-day concepts such as stock, flow, influence and object, many people are able to contribute to the model-design process; while the modeller knows that the result of the conceptual-modelling phase can be gradually fleshed out to produce a fully-defined model.
Many models are developed within a particular modelling paradigm (using the term paradigm in the dictionary sense of “a conceptual framework within which scientific theories are developed”). Thus, a particular model might be described as differential equation model, a System Dynamics model, an age-class model, a spatial model, a cellular automaton model, an object-oriented model, or an agent-based model. Some large-scale ecosystem models do combine two or more paradigms, but these tend to be implemented as large, unwieldy programs.
One of the strands that led to the development of Simile was to explore the extent to which all (or as many as possible) modelling paradigms could be handled within a single, easy-to-use visual modelling environment. This does not mean that each one has its own identity within Simile. Rather, it means that each one can be readily recast to fit within Simile’s model-design language. To a large extent, this is now possible: one model can have parts that are simple System Dynamics, other parts which are disaggregated into spatial elements or age-classes, and other parts that involve dynamically-varying populations of objects — all interacting with each other. The section on modelling approaches discusses these in detail.
Nevertheless, we are not claiming that Simile can handle all modelling paradigms. Areas that we wish to develop in the future include qualitative and rule-based modelling, multi-agent system modelling, and certain forms of within-model optimisation.
Simile is capable of handling models with several hundred equations. It is also capable of handling models with large number of instances (tens of thousands) of the same type of object. Both aspects mean that you do not hit a bottleneck as you move from prototype models to serious research models.
Simile simulates the behaviour of models by generating a computer program and then running this program. The standard language used is Tcl/Tk, which is an interpreted language and hence does not run particularly fast, roughly of the same order as other visual modelling packages. However, if you have a recommended C++ compiler installed, then you can simply choose to run the models in C++ : the whole run-time environment is identical. Models then run several hundred times faster : in many cases, roughly at the same speed as hand-written C programs.
Simile’s submodel concept provides a flexible but powerful approach to modularity — building a model up from a number of modules or components. At one extreme, Simile supports plug-and-play modularity: you can simply load a submodel, select an interface file, and all the links between the submodel and the main model are automatically made. This enables a community of researchers to agree on an interface standard, then engineer submodels to that standard. At the other extreme, you can simply load a submodel, then edit it and use influence arrows to link between variables in the submodel and those in the main model. This enables you to make use of other people’s (sub)models, even if they were not originally intended for use in your model.
Simile also supports “unplug-and-play”: the ability to extract a submodel from a model and run it as a stand-alone model. All inputs that previously came from the main model now appear as user-specified input values. This is extremely useful for checking out the components of a complex model.
In most, if not all, other modelling environments, you as the user are stuck with the input and output (display) tools provided by the software developers. This may not matter much if you are working in a specialised area such as electronics. It matters quite a lot for a generic modelling environment, when the range of systems that models can be developed for is so vast, and users requirements for visualising the behaviour of the model are so varied.
All the input/output tools supplied with Simile are Tcl/Tk programs stored as text files in one subdirectory in the main Simile directory. Simile builds up a list of the available tools each time you start it up. Any user of Simile, with access to someone who is prepared to program in Tcl/Tk, can add their own files to this subdirectory, either by copying and modifying the existing ones, or writing new ones from scratch. You can thus provide displays specific to the type of system you are modelling and your own display needs. Having done this, you can then share them with the Simile community. Thus, the whole community can contribute to Simile development!
Simile generates a computer program for running the model. It is possible to wrap this program up (for example, as a DLL or as a COM component) so that it can be embedded in other software systems. One example would be for a GIS which is capable of having software modules embedded inside it.
When you save a Simile model, it is saved as a text file in Prolog syntax. While it is not (and is not meant to be) human-readable, the format for this file is totally transparent. Anyone (with access to a Prolog programmer) can write programs for working with this file. One example is the Simile html model-description generator, a stand-alone Prolog program which produces an html file giving a complete description of any Simile model from the saved-model (.sml) file. This reflects our commitment to open modelling standards, with a variety of tools, produced by many different groups, for processing models in a variety of ways. Indeed, there is no reason why some other group shouldn’t set out to produce a visual modelling environment that competes with, or complements, Simile itself!