Dancing with models

<< Click to Display Table of Contents >>

Navigation:  »No topics above this level«

Dancing with models

Previous pageReturn to chapter overviewNext page

 

A simulator must work in conjunction with partner software if the goals of decision-support modelling are to be achieved.

A simulator, and particularly its parameters, hold information. History-matching harvests information from field measurements and transfers it to model parameters. This information is transferred to humans when they use the model to make a decision-pertinent prediction, and examine the uncertainty of that prediction. Ideally, its uncertainty is less than it would have been without history-matching.

Alternatively, history-matching may have demonstrated to a modeller that the system behaves a little differently from what he/she had previously imagined. Insights such as these benefit the decision-making process. They are the fruits of harvested information.

A simulator's dancing partner is likely to be a sophisticated piece of software in its own right, powered by a numerical algorithm that performs one or a number of complex tasks. In carrying out these tasks, it must run a model many times. We focus on model partner software algorithms in other sections. In this section we focus on the interface between a model-partner program and the model itself. Only an overview is presented. Refer to the PEST and PEST++ manuals for details.

There are two qualities that are integral to the way in which model-partner packages such as PEST and PEST++ interact with a model. They are as follows.

The model-partner interface must be non-intrusive.

The partner must be capable of running many instances of the model in parallel.

This section examines these issues in a little more detail.

dance