HarmonIT - Model Linking

Home

Model linking

Model linking is at a very early stage. The reason for this is that in many countries there has not been the legislative requirement or organisational structures to implement integrated water management. Consequently, the need and the funding to solve the problems have not been there. The costs of developing a generic solution to such problems are really only justified when it can serve a large user base. Until relatively recently, that base has not existed. As importantly, the computing power and fast communications to support linked modelling have not been widely available.

The first models generally addressed a single issue and were usually self-contained - see Figure 1. Model linking is a relatively recent practice. So far, it has been achieved either by running models serially, using the output of one model run as the input of the next - see Figure 2 - or by writing a very specific shell programme in which all the models are embedded - see Figure3.

Figure 1. Self contained model with no facilities for linking

A good example of the former is contained within a recent large coastal zone research programme. Here, the interactions of the rivers, estuaries, coastal waters and the deep oceans were modelled by taking the outputs of the river models and feeding them into the estuarine model and so on down the chain. This simple approach side-stepped many of the potential problems such as interfacing 1-D, 2D and 3D models working to different spatial and temporal concepts, scales and resolutions. It was merely necessary for the modellers to ensure a common understanding of the variables and agree an interchange file format. However, the approach was not able to represent many of the feed back loops, which, in other situations, might have been important.

Figure 2 Linking models serially by file transfer

Figure 3 Model linking to represent feed back loops

Where feed back has been important then, generally, modellers have stripped the models' codes out of their original shells and reassembled them in a new shell. The models have had their time steps synchronised and they have been run in parallel. Models of the interaction of river flow, chemistry and ecology are perhaps the best illustration of this approach. In this situation, flow and chemistry affect plant and animal growth, which in turn affects flow and chemistry. Running the models separately would completely fail to represent this interaction - see Figure 3.

A number of frameworks into which alternative models can be plugged have been developed but most have not progressed beyond the conceptual design stage and only a few have been implemented. So far, the frameworks have represented a specific situation. Each slot for a model has been for a particular type of model and the models used in that slot have generally had to work on similar principles. In most cases, these frameworks have been designed to run on a single machine. Few attempts have been made to model environmental situations where the models are geographically distributed running on different machines. The problems of joining two models together and producing scientifically sensible results has been challenging enough, without adding the complexities of attempting to do it through firewalls, across networks and operating systems, not to mention national frontiers. However, sufficient progress has been made to convince the members that a generic solution to linkage is now feasible and to justify their own investment in the project.

The major innovation that this project seeks to bring about is the introduction of 'plug and play modelling' in the same sense that it is now possible to plug most peripherals into most PCs either directly or via a network. To achieve this goal, similar problems have to be overcome. They fall into three classes: technical, standards and creating the collaborative environment in which users and developers benefit from the success of the work. The innovative aspects of the programme lie in all three areas.

The challenge is to analyse and characterise the generic nature of the information that passes between models, databases and other tools together with the situations that lead to a need to exchange data. Additionally to the links between models of the physical world such as hydrological and water quality models, links between these models and socio-economic models will be also considered. If a generic solution can be found, then it should be possible to conceive of a set of conceptual 'plugs, sockets, adapters, converters and cables' that will enable the information to be passed. However, these devices will only be useful if the sending and receiving models and databases have a common understanding of the information being exchanged, hence the need for standards. Just as different items of electrical equipment receive inputs and generate outputs in a whole range ways, so too do models. For example, some need to produce data on a daily time step while others use monthly or annual data. Some use raster spatial data while others are vector based. Therefore, there is a need for the equivalent of electrical adapters, transformers and converters to handle the equivalent problems of connecting incompatible plugs and making voltage, frequency and other conversions which equate, in modelling terms, to unit of measurement, scale, resolution, frequency, code, language and many other conversions and translations.

Our belief that a common interface is now feasible is based on the convergence of the members' individual approaches and our observation that the global trend in modelling and database design is towards the 'object oriented' paradigm. This provides the generic elements of objects, properties, methods and events in terms of which all model data and modelling activities can be described. The main technical problem is therefore one of developing a suitable class library that all modellers can use to pass information whatever its type. If the end result conforms to current and forthcoming industry standards, then it will be usable with most of the current programming languages used for modelling.

The result will be a standard Open Modelling Interface and Environment available to all modellers, which, if they choose to use it, will enable their models to be linked to any other model, database or tool conforming to the standard.

The communication standard opens the way for a number of advances that will help to facilitate the development of future DSS. A key aim in creating the communication standard is to encourage DSS designers to breakdown their systems into distinct modules, each with a clear function: user interface, model, database or etc. Not only is this good design practice anyway, but, if it can be achieved, then the way is opened up for drag and drop DSS construction. For each module, the inputs and outputs must be defined. The user will drag the modules from a series of menus to a construction area. Linking will be achieved by a further drag and drop process similar to the process by which tables are related in relational databases. Links between models and the database and models and the user interface can be achieved in the same way - see Figure 4.

Figure 4 Drag and drop modelling

Having created such an environment, it is easy to see that a demand for a range of tools will develop. An obvious example is a device to facilitate the calibration, validation and operation of the linked model. Others are the adapters and converters to enable models operating to different scales, resolutions and on different principles to communicate.

In such a scenario, exchanging one model for another for sensitivity testing and benchmarking should be relatively simple.

A technical solution alone, however, is of little use if the environment for its wide adoption has not also been created. An important element of the programme is therefore the involvement of all the key European producers and a range of users within the project.