GENIE BFG

What is the Bespoke Framework Generator (BFG)?

Author: Ian Henderson ([mailto:I.R.Henderson@reading.ac.uk I.R.Henderson@reading.ac.uk])

Last modified: 25/09/2006 12:03:00

Introduction
Climate model frameworks are often constructed using bespoke code tied to specific technologies. Such frameworks tend to be inflexible: it is difficult to add new models or swap existing ones, change the way the framework runs (e.g. from a sequential to concurrent mode, or vice versa), and programming effort is duplicated many times over as each framework uses its own implementation of common functionality. The University of Manchester Centre for Novel Computing is therefore developing a framework generator that climate scientists can use to produce customised ("bespoke") frameworks: this tool is called the Bespoke Framework Generator (BFG). The user supplies BFG with metadata about the models in the framework (their interfaces for initialisation and coupling), how they communicate (where coupling data comes from and goes to), and how the framework is to be deployed (e.g. the number of executables and MPI processes, and the order in which models should run). The user then runs BFG, which automatically generates appropriate framework source code from the supplied metadata. Where models are coupled using point-to-point communications embedded in the source code (e.g. MPI_Recv, MPI_Send, prism_put, prism_get), the user will need to substitute the function calls with calls to BFG "put" and "get" function calls, and specify the desired communications technology in the BFG metadata. BFG then creates appropriate "put" and "get" implementations that wrap the particular coupling technology requested by the user. (Framework metadata is currently supplied to BFG through a series of XML files that must be edited manually; it is possible that these BFG input files may be generated automatically from a GUI in future, which will guide the user seemlessly through the framework definition and generation process.)

Control code and "minimal compliance"
BFG will usually create the control code (timestepping code) for a model framework itself. However, BFG can still be used with models that contain their own control code. This may be desirable in cases where an existing model ' s control code is difficult to isolate. Models that only make use of BFG "put" and "get" and do not allow BFG to create control code are referred to in BFG terminology as having "minimal compliance". Such models must have one entry point subroutine that BFG can call to start the model, but apart from that all control is handled within the source code for the model itself: initialisation, timestepping and deinitialisation are carried out internally. The PRISM coupler, OASIS, is designed to work this way - it does not generate control code, instead relying on the individual models to control themselves.

Coupling through argument passing
BFG can be used to create flexible and extensible frameworks for existing sets of models, or to create such frameworks for new sets of models - an example of the former is GENIE; the latter, FLUME. Work with both these sets of ESMs is helping to drive current BFG development. The first version of BFG, BFG1, worked with toy models and only used point-to-point communication (put and get) for coupling. Coupling through argument passing (as used in the native GENIE framework implementation) was possible, but inefficient and obtuse. Table 1 below compares BFG1 and BFG2 methods for coupling sequential argument-passing models:

Argument passing simulated with BFG1 is undesirable because coupling fields are stored three times in memory unnecessarily.

Coupling with PRISM
Another development in BFG2 is the use of the PRISM coupler, OASIS (version 4). BFG2 will effectively wrap the OASIS functionality - BFG put and get will wrap prism_put and prism_get, and BFG will generate initialisation subroutines for each coupled model containing appropriate PRISM initialisation code that defines coupling fields ("transients" in PRISM terminology) and the grids over which those fields are exchanged by the OASIS coupler - prism_def_var, prism_def_grid, etc.. (To do this, appropriate metadata descriptions of model grids will be required - a "gridspec".) Note that BFG2 is designed to be coupler-independent - it will be possible to create frameworks that use different coupling methods in future just by specifying appropriate metadata.

BFG methodology
BFG methodology is summarised by the terms "Define", "Compose" and "Deploy" (DCD). These terms correspond to three metadata (XML) files containing definition, composition and deployment information for a model framework.

Definition
Note: an example definition file can be found in section 5.1.

BFG definition data is associated with each model within a framework. The definition data describes the interface to the model. The interface may either consist of entry point subroutines and their arguments (an argument-passing, or "argpass" interface), or put and get calls embedded in the model source code (an "inplace" interface), or a mixture of the two. Entry point subroutines comprise:


 * Initialisation subroutines, called at the beginning of a run to initialise the model;
 * Iteration subroutines, called periodically at specified timesteps during a run to update the model;
 * Finalise subroutines, called at the end of a run to deinitialise the model.

There may be more than one initialisation, iteration or finalise entry point associated with a particular model; where necessary, the order in which entry points are called can be specified using "constraint" data (e.g. "init1" precedes "init2"). Arguments to entry point subroutines are described by direction (in/out), datatype, dimension, and an ID corresponding to the position of the argument in the argument list. The argument definition does not include a name for the argument, just the positional ID. Entry points can also have "inplace" fields associated with them - puts and gets carried out by or under the entry point function.

Definition data is fixed for a given model, and doesn ' t change unless the model changes. Changes to composition and deployment data can be made without changing model definition data.

N.B. GENIE models and FLUME Met. Office models communicate by argument passing (rather than put and get). The need to create frameworks for models that use an argument-passing interface was one of the main drivers behind BFG2 (only inplace put and get style point-to-point communication was supported in BFG1). Put and get may still be used for diagnostic output in GENIE and FLUME though - it is considered easier to output diagnostics at the point in a model ' s code where they ' re calculated, rather than pass them up the call stack to an entry point function. This allows the separation of prognostic fields (arg passing), and diagnostic fields (in place output) in GENIE and FLUME. It is also possible to mix inplace and argpass field exchange: a field passed out of one model via an entry point function may be read in to another model via an inplace "get", for example.

Composition
Note: an example composition file can be found in section 5.2.

BFG composition data describes how fields are connected between models. This is done in two different ways for "argpass" and "inplace" I/O.

"Inplace" I/O
For inplace I/O (BFG "put" and "get"), output fields (puts) in models are connected with corresponding input fields (gets) in other models using "point-to-point notation": the IDs of input and output fields are matched up in the composition metadata. The notation used is uni-directional, and sometimes referred to as a "channel". (A similar method is used in the SMIOC metadata used in PRISM coupling.)

"Argpass" I/O
For argpass I/O (passing of fields through timestepping subroutines), set notation is used in the composition data to describe how arguments are connected across different models. Since the order entry point subroutines are called in affects how fields are connected across models, it was considered simpler to use set notation (rather than point-to-point) for argpass I/O - connections between fields are made by grouping together the subroutines that use a particular field, with no reference to where the arguments come from, as this is determined by the order they are called in in the deployment data (section 3.3.2). Figure 1 shows a set for coupling field "arg1":



Figure 1: arg1 (a coupling field) is shared by model timestep functions M1, M2 and M3 (no matter what order they are called according to the scheduling data)

BFG is able to work out whether arg1 is input or output from each model by analysing the definition data for that model. Coupled with the scheduling information described in section 3.3.2, BFG can produce code capable of calculating the source or destination of a field for each timestep at run-time. An example is given in Figure 2 (below) using M1, M2 and M3; it is assumed that the arg1 field is defined in the definition data as an "OUT" argument for M1, an "INOUT" argument for M2, and an "IN" argument for M3:



Figure 2: Example of BFG-generated control code where a field (arg1) can be "put" from different models depending on timestep

In Figure 2, M3 is not guaranteed to run sequentially after both M1 and M2 have completed and therefore the source of arg1 must be computed by get at run-time. The source put for the M3 get is determined according to whether the current timestep is even: if the timestep is even, the source (or "target") of the M3 get is the M1 put; otherwise the target is the M2 put. (In the current implementation of BFG2, target computation is performed by BFG functions called put_last and get_next.) The M3 get call will then block until the appropriate put has completed. (The fact that M2 is called every other timestep is part of the model definition data - see the example definition file in section 5.1.)

Note that it is only necessary to calculate the target of arg1 in a concurrent deployment of the model framework - M3 has been deployed in a separate executable from M1 and M2. Where all three models share the same executable and thread, BFG does not need to insert put/get message passing and put/get target computation because the models are guaranteed to run sequentially (see the right-hand column of Table 1 for an example of sequential argpass I/O). It would also be unnecessary to calculate the target for the M3 get if M2 used the arg1 field solely as an "IN" argument rather than as an "INOUT" argument - in that instance, the only possible source target for arg1 would be the M1 put.

Priming
Priming data describes how a field is initialised at the start of a run. Where a model uses "inplace" I/O for a coupling field, the priming of that field will always take place within the model ' s source code (i.e. internally), so no priming information is needed in the composition data. Fields that are coupled using "argpass" I/O (entry points) may either be primed internally, or may be primed by the BFG-generated control code, for instance set to a constant or obtained from a namelist file, NetCDF file, or another entry point subroutine (either from the same model or a different one) - priming information is always present for argpass fields.

Priming can work differently depending on how a framework is deployed - this can affect the output of experiments conducted with the framework, so needs to be considered carefully by BFG users. Table 2 illustrates the difference in priming between a concurrent model framework using OASIS for I/O ("inplace" I/O using prism_put and prism_get to pass fields between models) and a sequential model framework using BFG2.

Note that with BFG it is possible to prime and deploy the models in either of the two ways shown in Table 2.

Deployment
Note: an example deployment file can be found in section 5.3.

BFG deployment data specifies how a model framework will be run - how many executables and MPI processes will be used, what form of I/O will be used for communication between models (e.g. MPI, sequential, OASIS), and in what sequence model entry point functions will be called. BFG deployment data does not specify where the model framework will be deployed - on what platform or machine it will compile or run. Deployment data determines whether the framework (or parts of it) will run sequentially or concurrently.

Domain decomposition
Domain decomposition describes how the model framework is split into separate executables ("deployment units"), how many threads (sometimes referred to as "execution units", e.g. MPI processes) each deployment unit contains, and which models those threads control. The assignment of models to threads, alongside the information in the schedule, determines the sequence in which the models are run - hence the grouping of models according to thread(s) is referred to as a "sequence unit". Several possible domain decompositions are presented in Figure 3 below for a four-model framework (M1..4):



Figure 3: Three alternative domain decompositions for a four-model framework; DU = Deployment Unit, SU = Sequence Unit, T = number of Threads (Execution Units)

BFG2 is capable of creating control code for all three domain decompositions shown in Figure 3. The left-hand decomposition consists of one deployment unit (executable), with all four models running in sequence and using four separate threads (e.g. MPI processes). The middle decomposition shows the deployment unit split into two sequences (M1- > M2 and M3- > M4) controlled by separate pairs of threads - in practice allowing M3 and M4 to run before M1 and M2. The right-hand decomposition shows the framework split into two deployment units (executables).

Scheduling
Deployment data includes scheduling information - i.e. the order in which model entry point functions (e.g. initialise and timestep subroutines) run within a framework, assuming a sequential deployment. For instance, the schedule for models M1..3 timestep functions might be as follows:

M1- > M2- > M3- > M1- > M2- > M3- > M1...

The BFG metadata can also be used to describe the structure of more complex control code, e.g. for argument passing models like GENIE. BFG scheduling data is able to represent control code with inner loops or convergence based loops, and model timesteps are specified in the model definition data. (A model may run at a different timestep to the overall framework timestep and the timesteps of other models.) An example of such control code is shown in Figure 4. ! Main model framework timestep loop For Each timestep Call M1( args ) ! Different timestep If ( timestep Mod 2 ) Then Call M2( args ) End If  ! Inner loop For i = 1 To 5 Call M3( args ) End For End For

Figure 4: A more complex control code with different model timesteps and inner loops

Note that the schedule may not be executed sequentially if the domain decomposition specifies a concurrent deployment for the framework; parts of the schedule are only guaranteed to run sequentially if they belong to the same sequence unit. The schedule is therefore perhaps better described as providing the order for the control code rather than order of execution (which is a function of the schedule, model timestep, and domain decomposition taken together).

Code generation
A fourth metadata file (defined by "coupled.xsd") is used to group the DCD metadata files together, telling BFG where to find the model definition files and the composition and deployment files to use when creating a model framework. BFG then uses an XSLT processor to convert the XML metadata to source code capable of controlling and coupling the model in the way specified by the user DCD metadata.

In BFG1, code generation occurred in a single pass, but in BFG2 generation occurs over multiple passes as illustrated in Figure 5; this is due to the added complexity of generating control code for argument-passing models.



Figure 5: BFG2 code generation process

Auto arrays
Where the size of an array isn ' t known until run-time, BFG2 uses Fortran 90 allocatable arrays, which it ensures are allocated before first use. (Note that GENIE array sizes are fixed at compile-time in the current "native" implementation.)

Transformations
BFG2 currently has no set way of carrying out transformations. There are three kinds of transformations that have been identified:


 * Unit transformations, e.g. from Celsius to Kelvin;
 * Spatial transformations - projecting field values from one grid onto another grid, typically using a form of interpolation as carried out by OASIS;
 * Temporal transformations - the "rate matching" necessary when models are coupled at a different rate to their timestep, or where timesteps differ between models. For instance an atmosphere model might have a timestep of 30 minutes, and an ocean model a timestep of 2 hours, with coupling occurring every 24 hours.

When using BFG with OASIS, these transformations are carried out by OASIS itself. However, the BFG developers would like to support transformations independently of OASIS. For instance, it may be desirable for BFG to generate frameworks using MPI or sequential argument passing, and using the Spherical Coordinate Remapping and Interpolation Package (SCRIP) library for grid transformations.

GENIE framework generation
The BFG developers are currently working on an implementation of the GENIE framework that does not exchange geographical (gridded) data between models, and therefore doesn ' t need OASIS or SCRIP for spatial transformations. The temporal and unit transformations that are carried out are currently being included in the BFG-GENIE framework as models in the own right. The BFG-generated GENIE framework therefore consists of two types of model: "scientific" models, and "transform" models. This approach may or may not be used in future - another approach would be to include transforms in the BFG metadata.

Page footer 1

18