<< Click to Display Table of Contents >> Dancing with models |
![]() ![]() ![]() |
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.