neXtSIM-NEMO coupling

[einola]

This issue should be the main issue describing what is needed to couple neXtSIM to NEMO via OASIS. It may refer to other issues as they arise to allow us to focus on those.

Exchange fields required for the coupling

ice -> ocean

• ice-ocean stress in x-direction [Pa]
• ice-ocean stress in y-direction [Pa]
• ice-ocean stress magnitude [Pa]
• evaporation minus precipitation [kg/m^2/s]
• non-solar heat fluxes (longwave + latent + sensible) [W/m^2]
• short-wave flux [W/m^2]
• surface salt flux [kg/m^2/s]
• surface fresh-water flux [kg/m^/s]
• sea-ice concentration [0-1]

ocean -> ice

• ocean velocity in x-direction [m/s]
• ocean velocity in y-direction [m/s]
• sea-surface height [m]
• sea-surface temperature [°C]
• sea-surface salinity [PSU]
• height of first ocean layer [m]
• the fraction of short-wave radiation penetrating the first ocean layer [0-1]

Location of values on the (Arakawa) grid and vector rotation.

All values are passed at the centre of the cell (T-point), with the following exceptions:

• NEMO sends ocean velocities located at the U-point for x-direction and V-point for y-direction values.
• NEMO expects ice-ocean stresses located at the U-point for x-direction and V-point for y-direction values.

The two models have different definitions of x and y directions, so these vectors must be rotated before or after coupling. The most practical way to handle this is to interpolate both components to the centre (T) point, do the rotation there, and interpolate back to U/V points if needed. We may think of a more sophisticated way to handle this.

Tasks to complete the coupling

• [ ] Make sure neXtSIM calculates all the fields needed by NEMO
• [ ] Make sure neXtSIM can use all the fields provided by NEMO
• [ ] For fields calculated by neXtSIM, make sure we can pass the fields from the physics routine that generates them to the coupler interface
• [ ] For fields provided by NEMO, make sure we can pass the fields from the coupler interface to the physics routine that needs them
• [ ] Initiate the state of OASIS at the start of the run and close everything at the end
• [ ] Implement an OASIS "send" interface in neXtSIM
• [ ] Implement an OASIS "receive" interface in neXtSIM

See also issues #69 and #80

[einola]

Hi @timspainNERSC & @ericmaisonnave! Can you please read through this issue and see if it describes the problem in sufficient detail?

[timspainNERSC]

Are the velocities on U/V points for nextSIM-DG? As far as the Magdeburg dynamics are concerned, they are on a CG grid. Currently that is fitted to a set of DG components and then the DG0 value is passed back, which is defined at the T point, at the same point as everything else.

Presumably NEMO uses the U/V points.

This might be an argument for adopting and adapting the scheme interpolating to the T points, or it might be an argument that I need to look at the way the velocities are passed around again.

[einola]

You're right that in neXtSIM, the velocities and stresses are not at the U/V points but on a CG grid. I've updated the issue to make this clear.

[ericmaisonnave]

1. Velocities: it's possible to calculate these values at T point in NEMO, if needed (but I am not sure of the accuracy near the shore)
2. Cpl fields from ice to ocean, water: if "surface fresh-water flux" means, total E-P-R-C, with R=runoff and C=calving, it's fine for me. One would also send a runoff only variable, in a first step (again, it depends if we are building a demonstrator or a final operational model)
3. Cpl fields from ice to ocean, ice-ocean stress: NEMO also needs the atmosphere to ocean (wind) stress. On the ice covered region, it would better need the combination between wind and ice stresses (in one variable)
4. Cpl fields from ocean to ice: is neXtSIM really waiting for the fraction of short-wave radiation penetrating the first ocean layer ? And SSH plus first level height ?

[einola]

1. We can start by using the velocity calculation in NEMO. I hope it's better than whatever we would do, but we need to check this at some point.
2. I was thinking "surface fresh-water flux" == E-P-R-C, i.e. no separate runoff. But if the CNRM model setup expects runoff in a separate coupling variable, then we should also be able to do this in neXtSIM. It shouldn't be too difficult.
3. We will send the total surface stress, i.e. the wind stress where there's no ice and ice-ocean stress where there's ice. Over fractional ice cover, we calculate both and send the weighted average, weighted by the ice fraction. We'll start by calculating wind stress internally, but we should also be able to use Laurent's Aerobulk library (and other exchanges) to calculate wind stress.
4. NeXtSIM needs to know the fraction of short-wave radiation that heats the first ocean model layer. It'll use its own ocean albedo calculation, but it needs to know from the ocean model how much short-wave radiation escapes to deeper layers. For the same reason, it needs to know the thickness of the uppermost ocean layer, but I guess this is a constant + SSH in most cases.

[ericmaisonnave]

1. Masks are different in T, U and V grids. It means that some U or V values can be missing on the T point of the neXtSIM grid. That's why I propose to let NEMO interpolate the values on its T grid before coupling
2. ARPEGE will deliver separate values for R and C (different atmosphere/ocean interpolations) but neXtSIM can add all the water fluxes in one E-P-R-C value before sending to NEMO 3a. OK for receiving the total surface stress in NEMO 3b. As mentioned last Autumn in Grenoble, it should be possible to use OASIS for coupling Laurent's Aerobulk library. Tell me if you are interested (this is also something I would like to do)
3. OK to couple SSH + e3t(first_layer). If e3t stays constant, we will remove this coupling field.

[ericmaisonnave]

The latitude, longitude (center + 4 corners), mask and edge/NS angle variables for both Northern and Southern ORCA2 grids are ready (I send the netCDF files in a separate email to Tim). I adapted my ORCA/hemisphere input file converter to produce SI3 or neXtSIM input files. The netCDF format can be changed to fit neXtSIM requirements (please provide the specifications if any) All angle, latitude and longitude units are degrees. The 4 corner coordinates are provided in this order (for both N and S grids): 2-----1 3-----4

[einola]

I've pushed a branch called issue240_oasis_ocean_coupling to work on this issue.

I've created a new IOceanBoundary-derived module to handle the coupling in this branch. Most of the work Eric did in issue240_oasis_interface should be ported to here. In particular, what Eric put in the slab-ocean module should be in the new OASISCoupledOcean module.