Use CICE6 C-grid

[aekiss]

We should use the C-grid formulation in CICE6 when it is mature enough, to allow direct coupling with MOM6 on the same grid. See notes: https://github.com/COSIMA/access-om3/discussions/9

[aekiss]

If C-grid isn't working at the tripolar fold, should we consider a displaced pole grid? see https://github.com/COSIMA/access-om3/issues/36 But we'd like it to be exactly lat-lon in the southern hemisphere at least, for ease of analysis around Antarctica.

[kieranricardo]

Actually scratch what I said earlier, the displaced pole grid is exactly lat-long in the Southern Hemisphere.

[aekiss]

CICE6.5.0 has just been released, with improvements to the C-grid solver https://github.com/CICE-Consortium/CICE/releases/tag/CICE6.5.0

This isn't in CESM yet - might be another couple of months.

[aekiss]

Note: the CMEPS mediator doesn't understand C (or B) grids - currently everything is interpolated to A grid, exchanged, then interpolated back again. Need a mediator update to fix this.

@dabail10 do you know if there are any plans or timeline for native C-grid support in the CMEPS mediator? I couldn't find any open issues in CMEPS that looked relevant.

[dabail10]

There is nothing in the plans for CMEPS changes yet. I think this just requires a couple changes in the CAPs for MOM6 and CICE6. I think the mediator just does a pass through on fields ice->ocean and ocean->ice. So, we would leave everything on the native grid I believe?

[aekiss]

Ah, thanks for the clarification, that makes more sense and sounds like it would be easier to fix.

[aekiss]

Preprint: CICE on a C-grid: new momentum, stress, and transport schemes for CICEv6.5 https://doi.org/10.5194/gmd-2023-239 - this describes how the incremental remapping transport was modified to work without checkerboarding on a C-grid.

[anton-seaice]

Preprint: CICE on a C-grid: new momentum, stress, and transport schemes for CICEv6.5 https://doi.org/10.5194/gmd-2023-239 - this describes how the incremental remapping transport was modified to work without checkerboarding on a C-grid.

Thanks Andrew - We currently use advection='remap' (ice_in) which looks like it performs better.

It looks like the sea-ice volume reported is unchanged between B & C grid with the same advection scheme, although there are some reduction in thickness in thick ice.

[aekiss]

We'll need to wait for CICE6.5 before exploring C-grid, and I guess we'd want to wait until CICE6.5 is adopted by CESM before using it in ACCESS-OM3?

CICE6.5 is being used in CESM_CICE but CESM itself is currently using CICE6.4.1_10.

@dabail10 is there a timeline for adopting CICE6.5 in CESM?

[dabail10]

Should be going in to an alpha tag in the next couple weeks.

[anton-seaice]

I have been building / testing using CICE-Consortium main for a while without issues. I think using CICE 6.5.0 (or newer) for development / testing work will be fine for exploring this even before it's been updated in CESM.

[anton-seaice]

The coupling fields that would be impacted by moving to C-grid are:

From ocean to ice:

• tilt/slope terms 'So_dhdx'/ 'So_dhdy'
• velocity: 'So_u' / So_v'

These four terms exist as C-grid quantities in both MOM and CICE. We would need to configure MOM to output on C-grid and CICE to use C-grid. There are then two ways we could exchange the fields:

• Use exchange grids of the E/N points and add them to the drivers. We would have a mesh for scalars and two grids for vector quantities. I think this requires changing the drivers so that ESMF_FieldCreate calls are using the correct grids for the each field. (e.g. in MOM6 and in CICE6). In our (current) use case, the exchange grid for the ocean and sea-ice would be the same, so nuopc would still be attempting to regrid between the two grids, but there wouldn't be any work to do.
• Bypass NUOPC: Update CMEPS to have functionality for direct transfer of fields between components without going through ESMF. This would be most efficient, but probably not robust long term.

From atm to ice:

• velocity : 'Sa_u' / 'Sa_v'

I think there are two options here also:

• Use exchange grid: This term could be exchanged between the A grid (data-)atmosphere and C-grid cice using the exchange grid, but in this case NUOPC would be interpolating from the grid centers to the grid edges.
• Use CICE interpolation: CICE can also internally do this interpolation

I dont know which option would be better. ESMF would be on a lon/lat grid and CICE would be using the tripole grid.

From ice:

• ice -> atm stress : 'Faii_taux' / 'Faii_tauy' (we probably disregard these, the UM doesn't use them and nor does a data ocean).
• ice -> ocn stress : 'Fioi_taux' / 'Fioi_tauy'

These terms are more complicated, because they are combined with the 'Faox_taux' / 'Faox_tauy' terms in CMEPS. This is the ocn-atm stress which is calculated from wind + ocean speeds, so needs data from both components.

• Use exchange grid: I guess we want these quantities on the c-grid, so we would need to reproject the JRA data 'Sa_u'/'Sa_v' to C-grid before the calculation. Which probably means the mediator atm-oce flux calculation needs to have seperate grids for scalar and vector quantities. It looks like MOM6 cap already has the code to handle this flux coming in on the C-grid.

Caveat: i haven't considered any wave impacts yet

Open question is whether there is a grid / mesh format which supports having T/E/N points and grid cell area in it without needing three files.

[dabail10]

Thanks for this nice summary. There are still tricky pieces here. For example, we need speed (ustar) for the air-ocean stress calculation. So, we need U and V collocated somewhere to do this. We also need the ice fraction interpolated to the U and V points to weight the ice-ocean and air-ocean stresses. I am less worried about interpolating ice fraction as this is a smoothly varying quantity.

[anton-seaice]

Thanks for this nice summary. There are still trick pieces here. For example, we need speed (ustar) for the air-ocean stress calculation. So, we need U and V collocated somewhere to do this. We also need the ice fraction interpolated to the U and V points to weight the ice-ocean and air-ocean stresses. I am less worried about interpolating ice fraction as this is a smoothly varying quantity.

Thanks Dave

Does this mean we need qbot/zbot/tbot all colocated too? (e.g. https://github.com/ESCOMP/CMEPS/blob/7e0908cb958fc36002225efe00a3181f24c41c7a/cesm/flux_atmocn/shr_flux_mod.F90#L389)

I guess we will need three copies of ice fraction then, one on the A grid and one on each exchange grid. (or calculate them on the fly for the exchange grids).

[dabail10]

Exactly. We simply cannot avoid interpolating the atmospheric fields. They are all on the atmospheric A-grid. Currently they are interpolated (remapped) to the ocean A-grid / exchange grid. I think I will try a run with the existing remapping / interpolation.

[aekiss]

Also see @dabail10's slides, presentation, and subsequent discussion at the recent CESM Ocean Model WG meeting in which @Hallberg-NOAA explains how they avoid needing an exchange grid for MOM6-SIS2.

[aekiss]

PR https://github.com/COSIMA/access-om3/pull/129 upgraded CICE to a post-6.5.0 version from main, so we can start trying out C-grid CICE.

[dougiesquire]

We agreed in a meeting today that we'd like to push this forward. A proposed plan:

• [ ] Develop notebook/script for plotting key variables/diagnostics for assessing any impacts of changing to CICE C-grid
• [ ] Run baseline ACCESS-OM3 run using CICE B-grid
• [ ] Run ACCESS-OM3 using CICE C-grid without updating land mask or topography
• [ ] Use notebook/script to check/document that we are happy with CICE C-grid
• [ ] Update land mask and topography to take advantage of C-grid (note, without fast ice only the land mask updates are relevant to CICE, but it makes sense to update both together - see https://github.com/COSIMA/access-om3/issues/68)
• [ ] (Possibly) Tackle current restriction in CMEPS that everything is exchanged on A-grid

I think @anton-seaice may have already started a number of these steps?

[anton-seaice]

I ran the 1-degree RYF with CICE B-grid and C-grid. Sea ice area shows slightly more variability when using the C-grid, although sea-ice volume is consistently lower with the C-grid. Global T & S are higher using C-grid than B-grid, although maybe they would stabilise the same with enough run time. What other variables are we interested in? I guess some measure of advection ?

[anton-seaice]

They didn't report similar differences in Lemiuex et al 2024, so I wonder if maybe these will stabilise once the ocean stabilises? (Its not clear if an interactive or data ocean was use here, B-up is a different advection scheme we don't use)

From a CESM variant NH on top, SH on bottom:

[anton-seaice]

The difference in volume is much more pronounced in the Northern Hemisphere. Mostly this establishes in the first ~5 years and then is stable:

Looking at the global rate of change of volume doesn't reveal much - both b and c grid have similar rates of change, but just start with different amounts of ice. (Except for this interesting result: I think thinner ice in the c_grid leads to more flooding and therefore more snoice formation)

In general the ice in the c_grid is thinner (by quite a lot). This is a plot of difference in may in the last year of the run (in metres of thickness). Red means c_grid was thinner.:

There are also higher sea ice velocities reported with similar patterning in c_grid (red is faster in c_grid, differences in m/s):

[AndyHoggANU]

This could be implying that C-grid ice is less likely to pile up on the coast - which might actually be more realistic? My recollection is that we get some unrealistic pile-ups of ice in some places ...

[anton-seaice]

Thicknii look different compared to OM2:

In April

Both appear to be thinner than OM2, except in Canadian Archipelago, where its thicker in the new results?

In September

Those results seem intuitively slightly more realistic (maybe). Although I think in an RYF we would expect a fair bit of arctic ice to persist over summer, so maybe thinner is not more realistic here.

[anton-seaice]

Ice velocities through narrow channels look a bit different, it's not convincing c-grid is higher