Catering for MEDUSA coupling via OASIS3-MCT

Background

We need to cater for MEDUSA coupling at NEMO vn3.6 via the existing NEMO OASIS3-MCT interface and the Met Office UM code.

This work is initially primarily for the purposes of the UKESM project, however ultimately it is considered that the MEDUSA coupling interface would become a generally available option to any configuration which chooses to employ it.

Developmemt

The MEDUSA code itself is held in a development branch, created and maintained at NOC named, at time of writing, dev_r5518_NOC_MEDUSA_Stable This code potentially provides output fields to a coupler and receives input fields from a coupler to allow it to couple with an atmosphere model featuring dust and vegetation schemes.

Currently the specific coupling fields are expected to be:

• Output:
  • CO2 Flux (MEDUSA field f_co2flux2d)
  • DMS (MEDUSA field dms_surf2d)

• Input:
  • CO2 partial pressure (MEDUSA field f_pco2a. This is expected to come from the atmosphere and in the case of the UM specifically from the "TRIFFID" scheme)
  • Dust (MEDUSA field dust. This is expected to come from the atmosphere and in the case of the UM specifically from some special code which is as yet undeveloped!)

The code development needs to be compatible with the MO GO6 ocean model configuration. This configuration currently features approximately 11 separate code branches which makes further development of additional code potentially problematic in terms of a high risk of code conflicts.

It also needs to be compatible with the MO GC3 coupled model configuration which adds a further 4 NEMO branches.

While the bulk of the MEDUSA code is self contained under the TOP_SRC directory and thus less prone to causing conflicts, the coupling interface code is a very high risk in terms of conflicts since it needs to modify sbccpl.F90 and perhaps other high level coupling routines.

Oddly we find that the conflicts we see from the MEDUSA coupling interface developments are with code contained in the GO6 definition and not with the coupling specific code added by the extra GC3 branches. Specifically, we find that dev_r5518_coupling_GSI7_GSI8_landice_bitcomp is a major source of clashes. There is no way to rework the MEDUSA interface to avoid this because this branch, although only part of the GO6 configuration, actually features changes relating to coupled models (for reasons of avoiding code clashes!) particularly w.r.t. the magic numbers used for coupled field indexing.