C-grid bathymetry and land mask

[aekiss]

As mentioned in #36 (comment), at some point we should re-generate the topography and land mask to take advantage of using a C grid (narrower straits).

[aekiss]

C-grid land mask requires C-grid CICE, so if we opt for B-grid CICE we'll need to use a compatible land mask but could still use C-grid topography in all other respects.

[adele-morrison]

Amazingly well-documented repo showing where GFDL have made edits to their 1/4 deg OM5 topography here:
https://github.com/breichl/om5_topo_edits

[aekiss]

PR #129 upgraded CICE to a post-6.5.0 version from main, so we can start trying out C-grid CICE.

I think we should start by getting C-grid CICE running using the existing topography, and then re-generate C-grid topography.

[anton-seaice]

CICE doesn't use the bathymetry unless we turn on fast-ice, so there wouldn't be any need for a bathymetry change for CICE. We could update the land mask though for single grid-cell channels.

Does the bathymetry need to be updated for MOM ?

p.s. CESM did a long run of a similar config to ours with C-grid enabled in CICE and no coupling and found no issues. Its possible there is a stability issue with CICE c-grid at high resolution however.

[aekiss]

Ah yes, I was thinking "land mask" but typed "topography".

We don't need to update the topo or land mask for either MOM or CICE with C-grid, but at some point we should regenerate them to take advantage of C-grid being less restrictive, eg narrower channels. But before then I suggest we test C-grid CICE with existing topo and land mask.

[aekiss]

edit: moved this post to a new issue #172

[aekiss]

There will need to be tuning of the topography at important straits, since these will effectively be wider with a C-grid. See #139 (comment).

[aekiss]

We should make use of the tools https://github.com/COSIMA/domain-tools and experience COSIMA/mom6-panan#12 from generating the pan-Antarctic topography and land mask.
Also see this wiki page: https://github.com/COSIMA/access-om3/wiki/Topography-generation

[aekiss]

We used GEBCO2022 /g/data/ik11/inputs/GEBCO_2022 in the 1/20° and 1/40° pan-Antarctic topography, but GEBCO2023 is now available https://www.gebco.net/data_and_products/gridded_bathymetry_data/

I guess we should upgrade to GEBCO2023 for ACCESS-OM3?

[aekiss]

The latest ACCESS-OM2 topography is based on a much older version (GEBCO2014 v20150318) at all 3 resolutions. Nevertheless, at 1° and 0.25° we may want to use some of the hand-edits from ACCESS-OM2 and ACCESS-OM2-025 (see COSIMA/access-om2#158 for explanations), although some of these will need adjustment for a C-grid #139 (comment).

[adele-morrison]

It seems like many of the hand edits applied in COSIMA/access-om2#158 don't have an explanation? They were just edited to match where the old topography had been edited, is that right? I would advocate for not carrying over these old unjustified edits if possible. Do we have CMIP-schedule / people time to run without edits and see what problems arise? Or if not that, then what about comparing the new GFDL 1/4deg topography and seeing which of those original locations they still edited, and which they didn't?

[aekiss]

I agree we shouldn't copy these edits en masse. The old 1 deg topography had loads of hand-edits (over 540). The new ACCESS-OM2 topography has a total of 318 edits, including some of our own in the Red Sea and Northwest Passage. The values copied from the old topography were all carefully and deliberately chosen in discussion with Simon Marsland, who knew why they were there.

For the ACCESS-OM3 topography I think we'll need to use the ACCESS-OM2 edits (and test runs, and the GFDL 1/4 topography) to inform the edits we may need to make for ACCESS-OM3. Given that MOM6 is on a C-grid, and a very different model from MOM5, it would make sense to base our edits more heavily on GFDL (and our own test runs if we have time for that). Also, if our grids differ significantly (#172), direct comparison with GFDL or ACCESS-OM2 might not be very useful and we may need to rely more heavily on our own tests.

[aekiss]

Before finalising new bathymetry we should discuss whether any grounded icebergs should be to included - see #172 (comment)

[anton-seaice]

At some point in time, having the standard deviation of bathymetry within a grid cell could improve landfast ice representation (assuming we turn on the "probabilistic" sea bed stress for grounding of sea ice) . See this note from the cice docs:

It is assumed that the bathymetry (at the ‘t’ point) follows a normal distribution . The mean of comes from the user’s bathymetry field and the standard deviation is currently fixed to 2.5 m.

Given GEBCO is 500m nominal resolution, getting standard deviation should be possible (but maybe not totally reliable in areas of sparse measurements)

ping @adfraser

[adfraser]

@anton-seaice maybe but I can only see it being relevant in the Arctic. The bathy is too deep for keel grounding almost everywhere around Antarctica.
I guess we can calculate it offline later if needed. Also if someone eventually does iceberg grounding this will become important.

[access-hive-bot]

This issue has been mentioned on ACCESS Hive Community Forum. There might be relevant details there:

https://forum.access-hive.org.au/t/cosima-twg-meeting-minutes-2024/1734/12

[aekiss]

Also, although the GEBCO data is gridded to ~500m, the underlying obs data is much coarser in most places, so the standard deviation will be much less than reality, i.e. in most places the GEBCO dataset is much smoother than the real world would be at that resolution.

If roughness is important we could use something like synbath to get more realistic statistics.

[anton-seaice]

Happy to defer that until someone is trying to implement sea-bed stress for grounded icebergs :)

[aekiss]

GEBCO2024 has just been released (July 2024) - I guess we should use that for our new bathymetry instead of GEBCO2023?

GEBCO2024 hopefully fixes some known issues in GEBCO2023, including omitted obs data around New Zealand. So far there are no errata reported for GEBCO2024 but it's very early days.

[aekiss]

I've downloaded GEBCO2024 to /g/data/ik11/inputs/GEBCO_2024

[aekiss]

We might also want to explore MOM6's CHANNEL_CONFIG and porous barriers (Adcroft 2013) to represent narrow channels and sills, rather than editing the topography.

This may be particularly useful for configurations which include tides - see Wang et al 2024.

[aekiss]

There are example files specifying restricted channel widths in MOM6-examples.

[aekiss]

The only published examples I've so far found of the Adcroft 2013 method being applied are the Wang et al 2024 barotropic model and GFDL's CM2G (Wang, Legg & Hallberg, 2018).

[aekiss]

Comments from today's CMIP7 meeting:

Andy:
The porous barriers are interesting, but I think our initial plan should be to go with a regular grid, and test updating once we have a stable version.

Ian:
Porous barriers are sometimes used in the atmosphere, but they can lead to problems with other processes, eg. turbulence

[aekiss]

Finalising the land-sea mask is a high priority, as other components in ACCESS-CM3 and -ESM3 depend on it.

[aekiss]

GEBCO2024 has one issue so far in the errata:
Erroneous 'land' feature in the GEBCO_2024 Grid at 70.7934846W; 40.168019N.