pdf: 600KB - Potsdam Institute for Climate Impact Research

56
Most models of reasonable complexity will contain submodels. As just one example, the LPJ
model used in the ATEAM project for simulating forest dynamics contains a submodel concerned
with soil water dynamics using multiple soil layers. The ATEAM modeller decides to replace it
with an alternative. As mentioned in the Simile proof-of-concept section of this paper, that can
easily be done, by finding an alternative soil water model on the web, clearing the existing one,
and replacing it with the alternative - all with nothing more than a few mouse clicks. This
functionality can possibly be reproduced in other modular modelling environments. What cannot
be reproduced is the flexibility in interfacing that comes from a declarative approach: if the
interface between the new submodel and the rest of the model does not match, then you simply
use the standard model-editing tools to make the links. In contrast, most if not all modular
modelling environments are based on rigid interfacing for the modules.
Linking the model to others at the same level
This involves treating our model as a submodel, to be joined with one or more other submodels.
Again, this is straightforward: two or more empty submodels are created, and one model is loaded
into each one. Any linkages between them (presumably there are) can either be made manually,
by specifying that an input of one is a function of an output of the other. Alternatively, it can be
effected instantaneously for all required links, by calling up a file specifying the linkages between
the two submodels.
Replicating the model over spatial patches
In the ATEAM context, the model we loaded could well be a single-point model - e.g. a forest
stand model. We want the same model to be run in every grid square which actually contains
forest, retaining the same mathematical structure but allowing each instance to experience gridsquare
specific values for e.g. soil parameters and climatic variables.
Simile has demonstrated the ease with which a non-spatial model can be made spatial, given a
suitable design of model-representation language. It also shows that aggregating disaggregated
quantities (e.g. totalling across many spatial units) is straightforward.
Providing data
Running the model requires compatible data sets. In the context of ATEAM, the data sets are the
scenario files which are generated from GCMs (global change models), and other models and
approaches. Assuming that the model has inputs corresponding to those in the generated scenario
files, then linking the data to the model variables is simply a matter of choosing the appropriate
column in the data file (as it is in Simile at the moment). Appropriate formatting of data sets will
probably remain an issue, but lessened by the standardised way of representing model variables
that comes with a declarative modelling approach.
In the more general case, finding appropriate data for a model would probably involve searching
the web for data, in the same way that we searched the web for the model. Now, the computer
knows what the inputs are for the model: these will be variables that are not influenced by other
variables and do not have values assigned to them. In fact, it knows quite a lot about them, since
they will be probably be marked up with information defining their dimensions (e.g. length/time)
and - possibly - units (e.g. metres/sec). Additionally or alternatively, a variable might be
associated with a definition in a standard controlled vocabulary (such as the CABI Thesaurus, or
the FAO AgroVoc Thesaurus [see URLs]). This information, plus other information derived from
the model (time base, the nature of the submodels that a variable is nested inside) could then
enable the user to be automatically presented with a list of datasets available on the web which
contain appropriate data. This will be possible since these datasets will include metadata headers
conforming to the same ontology. The data could include species-specific parameters, timeseries
data (e.g. climatic records), or spatial information (e.g. rasterised information on land use or
elevation for the whole of Europe). Thus, matching up the data required by the model and the
data available in published data sets is potentially a straightforward operation, provided that the
appropriate metadata is associated with model variables and the data sets.