Thoughts on NorESM coupling

Introduction

The coupling of nextSIM-DG to NorESm is of a rather different character to how the coupling will work with OASIS. The latter will allow nextSIM to run as an independent binary, communicating through the OASIS library. For the former, nextSIM needs to have a another, very different form. Below are some of my thoughts on how to achieve this.

The form of the nextSIM

To couple to NorESM, nextSIM needs to be a library rather than an independent binary. This is then compiled into the NorESM binary to be run as a part of the coupled model. The library API should provide access to four functions:

1. Init
2. Import
3. Step
4. Export

These functions will be provided as C interface functions to allow the interaction with the Fortan core to be as painless as possible, both at compile time and at run time.

Init

The init function initializes the model with whatever it needs to be initialized. This would likely consist of the Model constructor, the tree of config() calls and the tree of calls to setData().

Import

The import function imports the data from the NorESM model into the subsidiary models. The current intention is for the data to be copied or pointed to by references that are part of the atmosphere & ocean boundary implementation that holds onto them until they are further referenced when PrognosticData::update() makes calls to the implementations of the atmosphere and ocean boundary layers. The data should only be copied a maximum of once, and should not have to be transposed. But consider the effect this would have on the grid for the dynamics.

Step

A function that emulates DevStep::update, including fetching the boundary data provided in the import step, a single iteration step of the the dynamics and thermodynamics and passing the data back for the export step.

Export

Similar to the import step, the export step provides the calculated model data back from nextSIM to NorESM. The data should be copied at most once, and not transposed.

Building DG/NorESM

The build type mechanism the CMake provides could be used to build the library form of nextSIM-DG for use with NorESM. This would involve a slightly different set of source files and would probably only include the ESM coupler implementations of the atmosphere and ocean communication routines. Depending on the specific requirements of coupling to NorESM, some other code might be in- or excluded.