DISEÑO METODOLÓGICO

There will be situations where the processes in two simulators of a particular system can’t be linked. It could be that there is no clear way to split the system up, or that it is very poorly understood. The simulators could model the system in terms of entirely different properties. However, even in pairs of simulators for which there are many matching processes, it is likely there will still be some events that are represented in one simulator but not in the other. For example, in OG99NPZD the zooplankton feeds exclusively on phytoplankton, whereas in HadOCC it also eats detritus. Not only does this create a series of nitrogen transfers involving detritus

4.3. Summary 64

in HadOCC that are not mirrored in OG99NPZD, it may also affect comparisons between HadOCC and OG99NPZD involving zooplankton feeding on phytoplank- ton. It is quite feasible that to produce plausible output, the zooplankton consumes more phytoplankton in OG99NPZD than in HadOCC, in order to compensate for not grazing on detritus.

It may be that if we are able to devise a method for emulating different simulators where the processes match up, as in Section 4.2.3, we can extend it to be able to deal with slight differences. However, jointly emulating two simulators that do not match up even at process level could be very difficult. At the most cautious level, one could derive a joint emulator f (x1, x2), where x1, x2 are the distinct sets of inputs

for the two simulators. This could then emulate both simulators’ outputs. However, in order to make this different from two separate emulators, one of each simulator, one would have to specify beliefs linking the behaviours of the two simulators, and this would require serious thought.

Figure 4.1 shows the processes modelled by HadOCC and OG99NPZD, and highlights any processes included by only one of the simulators.

4.3

Summary

In this chapter we have reviewed existing work concerning multiple simulators, and summarised some possible relationships between two simulators. We noted that at present, methods for emulation demand that the simulators be identical or very similar in terms of input space, and that this is a very restrictive constraint.

In the following chapter we introduce hierarchical emulation, a method for emu- lating simulators with simple extensions, as in Section 4.2.1. Intermediate variable emulation, which enables emulation of two simulators whose sub-processes can be at least partly matched, as in Section 4.2.3, and is therefore less restrictive, follows in Chapter 6.

4.3. Summary 65 Nutrient Detritus Phytoplankton Zooplankton D sinks

N released during grazing by Z P dies P respires P grows P eaten Z dies D eaten D remineralised D released in gra z ing Pgrazed Pdies Z excretes Z dies

Figure 4.1: Comparing processes represented by HadOCC and OG99NPZD. A dashed line represents a process that is only modelled by HadOCC, and a dotted line a process that is modelled only by OG99NPZD. A solid line shows a process that is included by both simulators.

Chapter 5

Hierarchical emulation

The first type of simulator difference, described in Section 4.2.1, was to have two simulators for which one, s1(x, v, w) is an extension of the other, s0(x). This is

a common occurrence, as there is often some choice over exactly which processes to include in a simulator, and how detailed to make some parameterisations. In this chapter we introduce hierarchical emulation, a method for emulation in this situation, and give an example using two versions of HadOCC.

Our concern is the scenario in which the two versions of the simulator can be made exactly the same by fixing the set of parameters v to a particular value v∗, so that

s1(x, v∗, w) ≡ s0(x) (5.1)

for all valid values of x and w. The set of input variables w contains those input variables belonging only to the more complicated simulator s1(·), but whose values

do not affect the matching up of s1(·) with s0(x) at v = v∗. We will refer to the set

v as hierarchical variables and w as extra variables.

5.1

An emulation structure

The structure of a hierarchical emulator enables us to emulate s1(x, v, w) in a way

that incorporates the information in Equation 5.1.

Firstly, assume that transformation functions gi(·) exist such that gi(v∗i) = 0 for

each hierarchical variable vi. Superficially this is not always the case, for example

5.1. An emulation structure 67

in the HadOCC example involving the carbon:chlorophyll ratio in Section 5.5 where making the two simulators equal involves a relationship between three of the inputs, however, by re-parameterisation it can be achieved.

The simulators can then be linked to one another in terms of some new functions ψ (·). With one hierarchical variable v, the more complex simulator s1(x, v, w) can

be re-written

s1(x, v, w) = s0(x) + g (v) ψ (x, v, w) .

At v = v∗, the two simulators are equal, and the relationship is preserved. This relationship is also used by Goldstein and Rougier (2009), where the more complex simulator, s0(·) in their notation, is a step toward making the simulator a better representation of the real system.

When there are k hierarchical variables v1, . . . , vk, this is complicated slightly.

Simply having an s0(x) term and a single hierarchical term k Y i=1 gi(vi) ! ψ (x, v1, . . . , vk)

will not work, because this will cause the two simulators to be equal when vi = vi∗for

any i, and this is not the case. Were we to use a function g (v1, . . . , vk), which was

zero only at (v∗₁, . . . , v_k∗), having a single hierarchical term could work, but this would make choice of the function g (·) quite complicated. To limit equality to vi = vi∗ for

all i therefore, we need to have at least

s1(x, v, w) = s0(x) + k

X

i=1

gi(vi) ψi(x, vi, w) .

However this still fails to express the relationship between the two simulators cor- rectly. For example, in the case with two hierarchical variables, v = (v1, v2), and no

extra variables w, this would give

s1(x, v1, v2) = s0(x) + g1(v1) ψ1(x, v1) + g2(v2) ψ2(x, v2)

and therefore

s1(x, v1, v2∗) = s0(x) + g1(v1) ψ1(x, v1)

5.1. An emulation structure 68

But this forces

s1(x, v1, v2) = s1(x, v1, v2∗) + s1(x, v∗1, v2) − s0(x) ,

which is not necessarily the case. Often interactions between variables have an im- portant effect on simulator output, and so to include these, the hierarchical emulator structure for k hierarchical variables must be

s1(x, v, w) = s0(x) + k X i=1 gi(vi) ψi(x, vi, w) + k X i=1 j>i gij(vi, vj)ψij(x, vi, vj, w) + . . . + g1...k(v1, . . . , vk) ψ1...k(x, v, w) , (5.2)

so that every possible interaction is allowed for. In some ways this is similar to func- tional ANOVA decomposition, where the main effects and interactions are modelled by separate functions (see, for example Kaufman and Sain (2010)). Now, each g·(·)

function must satisfy

g[i] v[i]
6= 0 ⇐⇒ vj 6= vj∗ ∀j ∈ [i],

where v[i] is the set of hierarchical variables associated with the function ψ[i](·). The

subscript [i] here denotes an index that may involve several numbers, for example the ψij(·) in Equation 5.2. A simple strategy, which we will follow from here, is to

have

g[i] v[i]
=

Y

j∈[i]

gj(vj) .

Note that the function g[i](·) uniquely determines the function ψ[i](·). We will con-

sider the implications of this in Section 5.2.3. Although this model looks somewhat complicated, conversations with others in the field suggest that it is rare for there to be more than a couple of hierarchical variables attached to any additional process.

Having decomposed the simulator s1(x, v, w) using the relationship in Equation

5.1, a hierarchical emulator can be built using a collection of standard emulators constructed as in Chapter 3