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

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.

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.

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 ?

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.

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.

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

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.