pdf: 600KB - Potsdam Institute for Climate Impact Research

57
Note the difference between a declarative modelling approach and a component-based approach.
In the latter, the metadata associated with model variables is quite separate from the model itself.
In contrast, in a declarative modelling approach the information about a variable is associated with
the actual variable in the model. Indeed, some of the 'metadata' for a variable is actually inferable
from information provided as part of the process of building the model - you don't need to provide
it separately.
Running the model
As discussed previously, running a declaratively-represented model involves either the use of an
interpreter provided within the modelling environment, or the generation of a computer program
which is then executed.
In a conventional modelling environment (or 'framework'), the model exists as a program: the
model is the program. All you can do is to run this program. In the declarative modelling world,
the model is separate from the program generated to simulate its behaviour. A separate
simulation or model-analysis program can be generated for each possible way of processing the
model. It is therefore possible for one model to be:
• run on a standard desktop PC;
• passed across to some web service to run the simulation;
• generate code for a parallel computer and run the model on that;
• run the simulation backwards (to see if we can backwards predict 1970 starting off in 2000),
for those models for which this is mathematically feasible;
• perform symbolic mathematics on the mathematical representation of the model (e.g. to derive
an analytical steady-state solution for a simple differential-equation model).
This is a significant benefit, since in a conventional modelling approach a separate program would
be needed for each task.
In ATEAM, the standard requirement is to simulate the behaviour of the model forward through
time. This is done for a variety of purposes: model benchmarking, validation, and the production
of results (behaviour of key indicators), which can then enter into the analysis of vulnerability.
This is a computationally-demanding activity, because of the size of the model, and the need to
run the models on a 10' grid for the whole of Europe and for a variety of scenarios. As mentioned
in the Introduction to this paper (Section 1), declarative modelling primarily addresses the issue of
managing the model itself, rather than performing simulations with the model. The runnable
version of the model is a program generated from its declarative representation, and is basically
the same as the (for example) a model represented as a component in a component-based
modelling framework. Therefore, the benefits of having a simulation environment, supporting
benchmarking, validation and other such activities, applies equally to models developed within
either approach.
Stakeholder involvement in the modelling process
So far, we have considered what it would be like to undertake ATEAM-style modelling in the
researcher's office. However, ATEAM is primarily concerned with the wider policy implications
of the threats of global change to ecosystem services. This involves the stakeholders both in
formulating the questions - what indicators are most relevant? - and as the audience for the results.
Currently in ATEAM, these interactions with stakeholders do not involve computer modelling:
the stakeholders are interviewed and fill in questionnaires, with the results stored in a database of
sectors and appropriate indicators and presented as a paper report.
There is now a growing feeling that stakeholders need to be more actively (or interactively)
involved in the modelling process itself (van Daalen et al, 1998; d'Aquinoe et al, 2002; Standa-
Gunda et al, 2002). Why? The main reasons are that the people affected by the results of a
policy-modelling process will be more likely to accept the results if they've been engaged in the
process; and stakeholders frequently can make valuable contributions to the modelling effort