1/20° topography

[AndyHoggANU]

It looks like we will begin a second attempt at a higher resolution (1/20°) PanAnt configuration. Last time we attempted this we simply sampled the old ACCESS-OM2-01 bathymetry to give the simplest possible 1/20° configuration. But that is probably not ideal in the longterm. Furthermore, @ChrisC28 is doing the same thing in mom6-eac (see https://github.com/COSIMA/mom6-eac/issues/6), so perhaps we should combine methodologies.

Possible options seem to be:

• The block subsampling that we used last time;
• Interpolating the 0.1° bathymetry?
• Sourcing a new and updated bathymetry and starting from scratch. It would be nice to think that the 3rd option is possible, but I don't know how possible it is.

Any suggestions or comments? Any other pitfalls we need to think about, especially in matching low resolution boundary conditions?

[adfraser]

(Probably more concerning is that the shelf itself isn't improved! But what can you do?)

[schmidt-christina]

Yes, the maximum depth and vertical grid is the same (and I assume the minimum partial cell height as well as I haven't modified anything, but I am not really sure where to look that up).

This is the relative depth difference:

[adfraser]

@schmidt-christina ah - that's a good way of looking about it - and now I see that the shelf is changed in many regions! Good stuff.

[aekiss]

Thanks - interesting that there are a few big relative differences in the open ocean. I guess the blue one near 60E, 60S is on the Kerguelen plateau?

[adfraser]

No, it's south of Kerg. Kerg is 50S. Edit: oops you said plateau. It looks like it's on the Elan Bank though.

[pedrocol]

I have a few comments, I don't know how useful they will be, but perhaps worthy to mention. I discussed this with Jean-Marc Molines, he did all the DRAKKAR bathymetries, and in particular, the bathymetry for the North Atlantic 1/60deg config (NATL60).

• For those who want to take a look to the last version of DRAKKAR 1/12deg global bathy: wget --no-check-certificate https://ige-meom-opendap.univ-grenoble-alpes.fr/thredds/fileServer/meomopendap/extract/eORCA12.L75/eORCA12.L75-I-JZ/eORCA12_bathymetry_v2.4.nc. This extended grid goes south until 85.7 (needed to include the cavities). Maybe interesting for comparison.

• He always perform changes manually at the coast, following a high resolution coast line (order 100m), and including very small bathymetric features (like islands, fiords, etc). This gives a very high realism look to the bathymetry, but he is sure that resolving all these bathymetric features has no impact on the large scale off-shore dynamics, and that maybe masking these places would had the same impact. These small features were not a problem when initializing the model in terms of stability, but the initial T/S data in those places is most likely not very precise.

• To finish, he also always performs a smoothing using a Shapiro filter, before introducing the mask. This is done to deal with some erratic values that may exist in the dataset and also considering that the dataset is created from different sources.

[aekiss]

Alistair Adcroft mentioned at the COSIMA workshop that several bugs were fixed recently in MOM6's handling of cavities so that "ceiling topography" is handled in the same way as bottom topography. So we should make sure we're using the latest MOM6 source code.

[adele-morrison]

Update on 1/20deg bathymetry from our meeting 20/1/23:

• Christina to update the bathymetry using the fraction parameter in domain-tools.
• Try running with this new bathymetry again (needs coupler mask). Also first check that we have runoff set to zero (and not constant runoff). @angus-g to check this with @schmidt-christina.

[schmidt-christina]

We still have issues with the bathymetry that @micaeljtoliveira is working on. We can't use the new bathymetry yet, especially because it has lakes again:

• depth in topog.nc also has depth values where the fraction is < 0.5 although I set it to 0.5
• ocean_mask considers the correct fraction but now ocean_mask and depth in topog.nc don’t agree
• after applying the fraction criterion new lakes occur (see one isolated yellow gridcell in ocean_mask)
• geolon_t and geolat_t are not the longitude and latitude, but again sea_area_fraction
• ocean_mask.nc doesn’t have coordinates
• NaNs should be something like -1e30

[micaeljtoliveira]

• geolon_t and geolat_t are not the longitude and latitude, but again sea_area_fraction
• ocean_mask.nc doesn’t have coordinates

These are now fixed.

Regarding the inconsistencies between the depth and the mask, after chatting with @aekiss about this, we agreed that we need to change the workflow and do things in a slightly different way as for ACCESS-OM2. In particular, all fixes to the topography, including setting the depth to zero for cells that have a fraction of ocean smaller than some value, should be done before generating the mask.

[aekiss]

At today's Antarctic Margins meeting Esmee Van Wijk commented that topography in the Denman region is quite different from datasets (e.g. bedmap), e.g. Denman trough is significantly deeper in reality, and some of the ridges might be over 100m too shallow in bedmap (and presumably GEBCO).

Steve Rintoul added that the thermocline is sharp and similar depth to ridges in this region, so can get critical transitions when water below the thermocline can make it over a ridge, so the combination of thermocline depth and bathymetry is important to get right in modelling. Much of the bathymetry data is from airborne gravimetry, which lacks spatial resolution, so smoothing reduces amplitude of extrema (troughs and ridges).

I may not have got all the details right - we could contact Esmee and Steve for more info.

[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/bathymetry-for-ocean-model-at-any-resolution/462/8

[aekiss]

Just noting here a new bathymetric dataset (SYNBATH) that fills in the gaps between multibeam tracks with statistically reasonable high-resolution synthetic data https://doi.org/10.1029%2F2021ea002069