GENIE Coupling

Coupling Introduction

Coupling, the controlled passing of scientific variables (sometimes known as "fields" or "transients") between models, is currently achieved using bespoke code within the GENIE framework. The GENIE community requires a more general and flexible coupling approach for the following reasons:

• It will be easier for modellers to couple new models and revised implementations of existing GENIE models (for instance, operating at new resolutions) if a standard coupling interface is used. In future, modellers will only need to provide coupling meta-data (perhaps via a GUI) -- specifying what fields are to be coupled on what grids -- without having to write bespoke code to implement the coupling itself.

• GENIE runs may be performed more quickly by harnessing the parallel execution facilities provided by a general coupler to run models simultaneously

• Alternative methods of spatial interpolation for translating variables between different model grids may be used without the addition of more bespoke code to GENIE. Sensitivity of the GENIE framework to different methods of interpolation -- for instance nearest-neighbour, bilinear, or bicubic -- can be investigated and assessed.

The GENIE earth system modelling framework will incorporate the Program for Integrated Earth System Modelling (PRISM) coupler, OASIS. The OASIS coupler is part of the PRISM community standard tool set for earth system models, and will enable the coupling of full complexity models in future. The "glue code" holding the framework together will be generated by the Bespoke Framework Generator (BFG). BFG will help insulate GENIE models from changes in OASIS (or allow the use of a different coupler in future).

What will be coupled and how?

This section outlines which GENIE models will be coupled, and provides more detail about how the coupling will be achieved.

IGCM and GOLDSTEIN

The GENIE team would initially like to couple the IGCM atmosphere and GOLDSTEIN ocean models (with slab sea-ice). By coupling two models that are already coupled within the GENIE framework, it will be possible to compare directly the results and performance of OASIS coupling with that for the bespoke coupling currently used in GENIE (largely implmented in Genie.F). In addition, IGCM and GOLDSTEIN use different spatial grids: long/lat for IGCM, and equal area for GOLDSTEIN. The use of different grids will allow investigation and comparison of the different interpolation algorithms provided by OASIS (nearest neighbour, bilinear, and bicubic). IGCM and GOLDSTEIN resolutions of 64x32x7 (T21) and 72x72x16 ("High") will be used to begin with.

OASIS4

The GENIE coupling project will use the latest version of the OASIS coupler, OASIS4. OASIS4 is a significant rewrite of the previous PRISM release, OASIS3. OASIS4 is currently at a beta release stage (functionally complete, but not stable). The GENIE coupling project will use OASIS4 for the following reasons:

• OASIS4 supports 3D field passing in addition to the 2D field passing supported by OASIS3. If we want to implement OASIS coupling for all GENIE model combinations, we will need OASIS4 because GOLDSTEIN-BIOGEM coupling passes 3D fields (as would future atmospheric chemistry).

• The significant change in the user interfaces for OASIS3 and 4: OASIS4 uses a different structure and language (XML) for metadata, meaning a time-consuming and costly switch at a later date if OASIS3 is used now.

• The use of a pre-release version of OASIS will also allow us to provide feedback to PRISM, helping to improve the coupler and benefitting both PRISM and the GENIE project.

BFG2

The GENIE coupling project will use the latest version of the Bespoke Framework Generator (BFG), a prototype implementation of the University of Manchester's Flexible Coupling Approach (FCA). BFG will be used to generate the framework code that "stitches together" IGCM, GOLDSTEIN, and the OASIS coupler. The BFG2 prototype is much more suitable than the BFG1 prototype because:

• BFG2 supports multiple entry points to a model - for instance the calling of explicit "initialise" functions as well as a "timestep" function. (GOLDSTEIN and IGCM have separate initialise and timestep functions.)

• BFG2 supports models with an argument-passing interface. (In BFG1, the model's timestep function could not take any arguments, and fields therefore had to be passed between models via BFG put and get function calls.)

Grids and Coupling

Most variables that need to be passed from one model to another are associated with various types and resolutions of geographic grid. Currently grid metadata (for instance type and size of grid) is embedded in the GENIE framework code itself, or included via GENIE-specific configuration files such as Fortran namelists. The OASIS coupler and BFG use metadata to represent coupling fields (or "transients"), but like the current GENIE framework code itself, there is currently no way to describe the geographic grids associated with the coupling fields. A central part of the GENIE coupling project is therefore to devise a suitable method for describing grid metadata that fulfils the following requirements:

• Can represent all GENIE model grid metadata required by the PRISM coupler, OASIS.

• Be suitable for processing by BFG, which will use the grid metadata in the automatic production of GENIE framework code. BFG requires sufficient grid metadata for creating PRISM grid initialisation subroutine calls, and for use in the creation of the PRISM SMIOC (Specific Model Input and Output Configuration). BFG will also use the grid metadata to initialise the GENIE models (e.g. create the "initialise_atmos" call to initialise IGCM with the resolution specified in the grid metadata).

• Is sufficiently general so that it can be extended to support grids used by models outside the GENIE framework. Particular attention should be paid to representing the grids used by the UK Met Office, in particular for their new Flexible Unified Model Environment (FLUME).

• Adopts a structure and format similar to the grid specification prototype currently being worked on by V. Balaji. Balaji's prototype gridspec was presented at the May 2006 metadata meeting, hosted by the Met Office.

Work plan

The following tasks comprise a relatively short-term work plan. This plan will be modified and extended as work progresses.

1. Identify the metadata needed by OASIS for the GENIE models (physical interface, grids and interpolations, currently in genie.F). As part of this, an OASIS4 toy model will be written to determine what data is required to initialise OASIS with the grids used by IGCM and GOLDSTEIN. [Ian]
2. Create a grid metadata description ("gridspec") based on Balaji's prototype, and suitable for describing the metadata required for IGCM and GOLDSTEIN (as determined above). The gridspec will be developed with input from the GENIE community, PRISM, the BFG developers (University of Manchester), the Met Office, NCAS-Climate (University of Reading), and Balaji. Development of the gridspec will be iterative, starting with an initial prototype that can be used to generate feedback from interested parties. [Ian to lead]
3. Once an agreed gridspec has been developed, BFG will use it to create the appropriate PRISM grid initialisation calls, model initialisation calls, and PRISM metadata (SMIOC). The resulting BFG-generated version of the GENIE framework will be capable of running the prescribed models (IGCM atmosphere and GOLDSTEIN ocean) with grid coupling and interpolation. [Ian + BFG developers]