pdf: 600KB - Potsdam Institute for Climate Impact Research

38
7.5 Software tools for processing models
With conventional modelling, the program used to implement the model is at the same time the
tool used to do one particular task with the model: simulate its behaviour.
With declarative modelling, we separate the representation of the model from the tools available
to process it in some way. One such tool can be a simulator; but there are many other useful
ways of processing a model apart from simulating its behaviour. The same tool can be re-used for
any model expressed in our model-representation language. Conversely, the same model can be
processed by a wide variety of tools, depending on what we want to do with the model.
What do is meant by 'processing the model'? Well, one major aspect is to produce a runnable
version of the model: this enables us to simulate the behaviour of the model. This is what we
normally think of doing with a model and, because it is so important, it will be discussed in more
detail below, in Section 7.6. Other forms of processing are considered here:
Designing and editing a model
When a model is considered as a declaratively-represented design, we can envisage software tools
to support the process of designing and editing the model - a computer-aided design (CAD)
package for ecosystem modelling. There are a number of visual modelling environments that
support System Dynamics modelling, such as Stella, Vensim, Modelmaker and Powersim.
Simile is another example, and is described in Section 8. In Simile's case, the resulting model can
be saved in an open, text-based model-representation language, and thus available for processing
by other, independently-developed tools.
Displaying model structure
Tools can be developed for displaying model structure in a variety of ways. Section 8.3 gives
examples of tools for displaying any Simile model as HTML (a web page, viewable in a web
browser, with hyperlinks between different parts of the model), as a diagram viewable in a web
browser, and even as spoken text, for people with impaired vision.
Comparing two models
Consider the case of groups within a research programme developing a joint model, then work on
it independently for 6 months. They then want to compare the two versions, with a view to
possibly merging them or discussing differences. If the model is a program, then at best they can
use text-comparison ('diff') software. It would be far better if the actual design of the models
could be compared, and this is only possible if the models are represented declaratively.
Transforming one model into another
The declarative representation of a model consists of a set of symbols. These symbols can be
manipulated by an appropriate computer program to produce another set of symbols, which can
represent the design for a different model. In other words, it is possible to transform one model
into another. Muetzelfeldt and Yanai (1996) introduce this concept in the field of ecological
modelling.
There are two main uses for this in ecosystem modelling. The first is to explore alternative
designs automatically. Any model embodies a large number of design choices, many of which
could well have been different if the model had been developed by a different but equally-skilled
researcher. Do these differences matter? The only way is to build a variety of models and try
them out. Conventionally, this would require hand-coding the changes into the model program
(and thus is rarely done), but a model-transformation tool, drawing on a body of knowledge about
legitimate alternative designs, could do this automatically.
The second is in scaling, and simplifying complex models. There is frequently a need to simplify
complex models in order to make them computationally tractable, and to enable general principles
of their behaviour to be analysed (see Dieckmann et al 2000 for a detailed study of this in the