New grids

[aekiss]

Before redoing the topography (#68), we should take the opportunity to check whether the grid can be improved.

e.g. consider

1. whether the tripolar points would be better located elsewhere, e.g. at lower latitude and/or further from the Gulf of Ob
2. whether a different location for the longitudinal seam would be more convenient for our purposes (is it inconvenient to have the seam in the Indian Ocean?)
3. whether the C-grid zonal velocity points should be on the equator as done in CESM3 providing symmetry for upwelling and waves (@gustavo-marques tells me they did this in CESM3 hoping for equatorial wave improvements but it didn't make much difference)
4. extending closer to the south pole to include ice shelf cavities as was done in the 1/20° panAntarctic config 1/20° topography mom6-panan#12 (comment)
5. refining grid in the Antarctic / coarsening in the Arctic Refine grid in Antarctic? #67
6. quantizing double-precision values so they are exactly representable in single precision (as we do in the vertical grid)

Does anything else spring to mind?

[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-working-group-announce/238/73

[adfraser]

Hi Andrew,
2) Longitude seam: Other than at the peninsula, around 140 E has the narrowest meridional sea-ice extent - is that what you were thinking? But is it a concern to have the seam in "our turf" - East Antarctica? Would it be crazy to have the seam at the peninsula? Isn't the seam longitude somewhat set by the NH tripole locations? (take all with a grain of salt - I don't know much about models!)
4) definitely has my support!

[adele-morrison]

Good points to think about! Might be nice to bring this discussion up at a COSIMA weekly meeting?

[PaulSpence]

IInteresting questions. It is a rare opportunity to change the grid. Hard to know where and how much to invest in grid changes. Probably less modifications is best, considering the effort required to determine results. Item 4 above seems like a no-brainer modification though.

[adfraser]

Raising a new point here: @pwongpan and I realised that large tabular grounded iceberg D15 is not in the 0.25* grid (and presumably the .1 and 1.0 grids either).
Here are snapshots from 1997 (top) and 2024 (bottom) showing D15 (labelled as "grounded iceberg") against the 0.25 degree grid.

Even without cavities being implemented, I'd argue that D15 would be better treated as land pixels than open ocean pixels for the following reasons:

• It's easily resolved in the 0.25 and 0.1 degree grids. It's even 2 pixels in the 1 degree grid, I think.
• I am pretty sure it's grounded to the north, and likely occupies the majority of the water column for its entire length. So it's a major impediment to the passage of currents.
• It's been there for donkeys years (it's basically calved from the West Ice Shelf but remained in place).
• It's starting to break up but the main part is very much not looking likely to move any time soon.
• It's far more stable and long-lived (in the same place) than icebergs A23A and B9B. It's basically the most stable glaciological feature which probably should be included in the land mask, but isn't.

Can we consider prescribing this as land pixels for the OM3 grid? Obviously when cavities are implemented, it would make more sense to describe this as a cavity, but until then I think land is better than water. Just a discussion point - there may be ocean things I haven't thought of :)

[adele-morrison]

Out of interest, are there any grounded icebergs included in the current bathymetry? I think we just use bathymetry from GEBCO that doesn't have any icebergs in it?

[adfraser]

I suspect none. @dpath2o might know more

[ofa001]

Hi @adfraser @adele-morrison @dpath2o I would think it odd from a coupled model perspective to have the icebergs as land points in any new grid. For Dan's project it might be useful but he can put them in for that, but these grids will need to be used more widely. Upto now we havent been using icebergs in the grid, and we just had to redo the Antarctic because minor ice shelves weren't handled well in earlier bathymetry version. We need to improve things for the next iterations in access-om3/cm3

[adfraser]

Thanks @ofa001 - yeah I realise they will need to be used widely but I think including D15 could be a special case for the "base" grid. Just a thought.

[anton-seaice]

1. whether the tripolar points would be better located elsewhere, e.g. at lower latitude and/or further from the Gulf of Ob

The difference in area for some of these cells (as described in 126) seem fairly drastic, so this looks worth investigating further.

From Bi et al 2013:

In panel a), it looks like we would move the poles south-west to maximise the distance from the ocean. I suspect they will need to be 180° in longtitude apart for us not to break something.

2. whether a different location for the longitudinal seam would be more convenient for our purposes (is it inconvenient to have the seam in the Indian Ocean?)

In theory, moving this to the longitude to with the smallest length of ocean would reduce the amount of communication between MPI tasks but the effect would very marginal.

It would be nice to have Australia in the middle of our plots :)

3. whether the C-grid zonal velocity points should be on the equator as done in CESM3 providing symmetry for upwelling and waves (@gustavo-marques tells me they did this in CESM3 hoping for equatorial wave improvements but it didn't make much difference)

Its nice to have the equator on the edge of grid cells, just because its easier to understand I think (and maybe easier to analyse?)

4. extending closer to the south pole to include ice shelf cavities as was done in the 1/20° panAntarctic config 1/20° topography mom6-panan#12 (comment)

Sounds like we have consensus on doing this, but leaving the ice shelves landmasked for now.

5. refining grid in the Antarctic / coarsening in the Arctic Refine grid in Antarctic? #67

Coarsening in the Arctic could help with 1. ? But will refining the grid in the Antarctic force us into a shorter time-step also? The cells at the south (panel b above) are already somewhat out of square, which does increase CORRECTION: we don't want the cells at the Southern end to get too far out of square, becuase it increases the amount of communication needed between MPI tasks (to communicate quantities between processing blocks). We might be able to refine the shape of the processing blocks to avoid the extra communication though :)

Does anything else spring to mind?

I guess we will keep these refinements for 1 degree (Bi et al 2013):

In the meridional direction the grid spacing is nominally 1° resolution, with the
following three refinements: a) tripolar Arctic north of 65°N;
b) equatorial refinement to 1/3° between 10°S and 10°N; and
c) a Mercator (cosine-dependent) implementation for the
southern hemisphere, ranging from 0.25° at 78°S to 1° at 30°S.

We should make sure the new grid files are cf-complaint. CMS have a compliance checker which would help: http://climate-cms.wikis.unsw.edu.au/CF_checker

[ofa001]

Hi @anton-seaice In realtion to the Antarctic, the choice of grid there in the BI et al "auscom" grid used in access-om as well was to be "square" so that n/s resolution was close to the e-w resolution as the we went further south, it might look a bit skewed on the plot. I would support additional resolution as its our region of interest, but we still need to keep some resolution in the Arctic (for both ice and ocean processes). But its less of a priority.

[anton-seaice]

Thanks :) Ill correct my post .

[anton-seaice]

2. whether a different location for the longitudinal seam would be more convenient for our purposes (is it inconvenient to have the seam in the Indian Ocean?)

On further thought on this point, by definition the location of the longitudinal seam is the longitude of one of the tripoles. From the Murray 1995 paper:

The curves are constructed on a NH stereographic projection about foci, F1 and F2 , lying on either side of the N Pole (N), which is the origin of the projection (Fig. 9). The foci are situated at latitude phiF (...) and 90° east and west of the symmetry meridian, which is at longitude l0. The focal arc and the symmetry meridian define the x and y axes, respectively.

The key point being the symmetry meridian (90° offset in longitude from the tripoles), which is continuous across the orthogonal and stereographic sections of the grid:

The definition precludes us from defining the location of the longitudinal seam differently than the tripole, although there may not be a mathematical reason why the longitudinal seam and the tripoles need to be aligned in longitude.

[anton-seaice]

@adfraser Also just pointed out that moving the tripoles south will force the resolution in the Arctic to be lower, which is probably desirable for us.

[anton-seaice]

Apologies for the talking to myself: @pwongpan asks if we should consider IBSCO bathymetry in the Southern Ocean. It looks like the GEBCO_2023 has assimilated latest fairly up-to-date IBSCO already. From https://www.gebco.net/data_and_products/gridded_bathymetry_data/gebco_2023/:

The SRTM15+ base grid has been augmented with the gridded bathymetric data sets developed by the four Seabed 2030 Regional Centers to produce the GEBCO_2023 Grid. The Regional Centers have compiled gridded bathymetric data sets, largely based on multibeam data, for their areas of responsibility. These regional grids were then provided to the Global Center. ... For the polar regions, complete grids were provided due to the complexities of incorporating data held in polar coordinates.

The compilation of the GEBCO_2023 Grid from these regional data grids was carried out at the Global Centre, with the aim of producing a seamless global terrain model.

[adfraser]

As long as the new GEBCO has IBCSO2, not IBCSO1? IBCSO2 was a major update

[anton-seaice]

As long as the new GEBCO has IBCSO2, not IBCSO1? IBCSO2 was a major update

Yeah it does: see data_contributors and search Southern Ocean

[adfraser]

That's great then. I consider IBCSO2 the best available for the SO

[pwongpan]

Thanks all. I don't know how complicated it is, but it would be great to have a platform/cookbook where we could regenerate the bathymetry based on the new bathymetric observations (by icebreakers, Expendable Bathythermograph etc.) from the grid of interest.

[adele-morrison]

@pwongpan these tools exist and have been used for past models (ACCESS-OM2, panan): https://github.com/COSIMA/domain-tools

[anton-seaice]

4. extending closer to the south pole to include ice shelf cavities as was done in the 1/20° panAntarctic config

It is suggested in the ocean grid generator guide when doing this that the South Pole should be offset to maximise the distance from the Ice Shelves (which will lead to less tiny grid cells which could be ocean). The Ross Ice Shelf looks to extent past 85°S, so its probably worth considering.

Screenshort from nilas.org :)

[adele-morrison]

Hmm, yes, good point @anton-seaice. That would make analysis a pain doing zonal averaging though!!!

[anton-seaice]

Hmm, yes, good point @anton-seaice. That would make analysis a pain doing zonal averaging though!!!

It could/should be possible to start the 'displaced pole' section at say 78°S, so for most configurations it would all be within the landmask.

[dpath2o]

Thank you! This is very intriguing. Is this grid found in ik11? Cheers, Dan Daniel Atwater PhD Student (part-time, remote-based) IMAS — AAPP (Theme 3, Project 6) ***@***.*** +61(0)429 914 545

…

________________________________ From: ezhilsabareesh8 ***@***.***> Sent: Wednesday, September 11, 2024 2:16:30 PM To: COSIMA/access-om3 ***@***.***> Cc: Daniel Atwater ***@***.***>; Mention ***@***.***> Subject: Re: [COSIMA/access-om3] New grids (Issue #172) A new 025 grid, bathymetry, initial conditions and surface salinity restoring files has been created with the following changes: * The tripole points remain unchanged. * The longitudinal seam remains as-is. * Zonal C-grid points have been placed on the equator. * In the Antarctic, the Mercator region has been extended to 75°S, followed by constant dx extension to the southern edge of the grid, without any coarsening in the Arctic. * GEBCO2023 topography The comparison between the OM2 and the new grid can be found in this notebook<https://github.com/ACCESS-NRI/access-eval-recipes/blob/main/grids/Checks_grid_metrics_for_new_025_grid.ipynb>. Initial conditions were generated using the GEBCO 2023 dataset, and a comparison between the 2013 and 2023 datasets is available here<#161>. Additionally, topography has been updated for the new grid, and the comparison of surface salinity restoring between the two datasets can be found here<#207>. The simulation with the newly generated files crashes after six months due to truncation, while the current 0.25-degree configuration with OM2 files runs for two years. As Andy noted, truncations signals model approaching instability. This could be due to changes in topography or initial conditions affecting stability. FATAL from PE 45: write_energy : Ocean velocity has been truncated too many times. I am trying the simulation with a reduced timestep to see if that resolves the issue. Additionally, I am checking if the crash consistently occurs at the same location, which could indicate the need to adjust the new bathymetry. — Reply to this email directly, view it on GitHub<#172 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAM3G66JK4RVTBUQNVMUYA3ZV67Z5AVCNFSM6AAAAABIETA476VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBSGU4DMMRQGE>. You are receiving this because you were mentioned.Message ID: ***@***.***> This email is confidential, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone outside the intended recipient organisation is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender. The views expressed in this email are not necessarily the views of the University of Tasmania, unless clearly intended otherwise.

[ezhilsabareesh8]

Thanks @dpath2o , This grid is still in the testing phase so it is not available in ik11. It can be found in the following directory in case you need it.

/g/data/tm70/ek4684/New_grid_input_files_025deg_50zlevels

[gustavo-marques]

Instead of reducing the time step, you can find out where the truncations are coming from and maybe solve that problem by changing the topography, for example. To do so, allow truncation by setting MAXTRUNC = 10000. To find out where in the domain the CFL is being violated, you also need to define the files where the accelerations can be written (e.g., U_TRUNC_FILE = "V_velocity_truncations", V_TRUNC_FILE = "V_velocity_truncations").

…

On Tue, Sep 10, 2024 at 10:16 PM ezhilsabareesh8 ***@***.***> wrote: A new 025 grid, bathymetry, initial conditions and surface salinity restoring files has been created with the following changes: - The tripole points remain unchanged. - The longitudinal seam remains as-is. - Zonal C-grid points have been placed on the equator. - In the Antarctic, the Mercator region has been extended to 75°S, followed by constant dx extension to the southern edge of the grid, without any coarsening in the Arctic. - GEBCO2023 topography The comparison between the OM2 and the new grid can be found in this notebook <https://github.com/ACCESS-NRI/access-eval-recipes/blob/main/grids/Checks_grid_metrics_for_new_025_grid.ipynb>. Initial conditions were generated using the GEBCO 2023 dataset, and a comparison between the 2013 and 2023 datasets is available here <#161>. Additionally, topography has been updated for the new grid, and the comparison of surface salinity restoring between the two datasets can be found here <#207>. The simulation with the newly generated files crashes after six months due to truncation, while the current 0.25-degree configuration with OM2 files runs for two years. As Andy noted, truncations signals model approaching instability. This could be due to changes in topography or initial conditions affecting stability. FATAL from PE 45: write_energy : Ocean velocity has been truncated too many times. I am trying the simulation with a reduced timestep to see if that resolves the issue. Additionally, I am checking if the crash consistently occurs at the same location, which could indicate the need to adjust the new bathymetry. — Reply to this email directly, view it on GitHub <#172 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWQLALKBIT6L6VLY4WJE23ZV67Z5AVCNFSM6AAAAABIETA476VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBSGU4DMMRQGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Gustavo Marques NSF National Center for Atmospheric Research phone: 303-497-174 <(303)%20497-1737>*0* Climate & Global Dynamics fax : 303-497-1700 <(303)%20497-1700> PO Box 3000 Boulder, CO 80307-3000 http://www.gustavo-marques.com

[ezhilsabareesh8]

Thanks @gustavo-marques. I’m looking into the issue already by setting the MAXTRUNC = 5000, the simulation runs for over a year without any issues. The truncations are occurring at a particular time step, with the maximum number being 45 on September 5.

Ntrunc = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 3, 7, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 45, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,  

However, despite enabling the truncation files in the MOM6 input (with U_TRUNC_FILE and V_TRUNC_FILE specified as required), I haven’t seen any truncation files in the output. I’m currently investigating why these files aren’t being generated.

[ezhilsabareesh8]

The issue with producing the truncation files still persists. Even though I’ve enabled debug truncations, debug and specified U_TRUNC_FILE, V_TRUNC_FILE in the MOM_input, MOM6 is trying to write an empty V_velocity_truncation file, and Payu is sweeping all the empty files. When I changed the directory path for the truncation files, I was able to find an empty V_velocity_truncations file.

In the hourly output, the max V velocity shows a sudden increase in the northern Hudsons Bay on the 29th of July before crashing due to truncations.

Bathymetry:

By setting the MAXTRUNC = 5000, the simulation runs for 4 years without any issues and the maximum number of truncations per day reduced to 10 from 46.

[gustavo-marques]

Thank you! If you still have two runs with different MAXTRUNC but otherwise identical, please verify if the solution has changed by comparing ocean.stats. If changing MAXTRUNC changes the solution, we should open an issue in https://github.com/mom-ocean/MOM6

[aekiss]

By setting the MAXTRUNC = 5000, the simulation runs for 4 years without any issues and the maximum number of truncations per day reduced to 10 from 46.

Do you mean that the number of truncations in year 1 has reduced (which would be weird / a possible bug), or the number of truncations in year 4 is fewer than year 1 (which is what we'd hope as spinup proceeds)?

If the latter, can we safely reduce MAXTRUNC (e.g. to the default) after the initial few years?

[ezhilsabareesh8]

Do you mean that the number of truncations in year 1 has reduced (which would be weird / a possible bug), or the number of truncations in year 4 is fewer than year 1 (which is what we'd hope as spinup proceeds)?

The number of truncations in year 4 is lesser than year 1.

If the latter, can we safely reduce MAXTRUNC (e.g. to the default) after the initial few years?

The default value is zero, but in years 3, 4 and 5, the maximum number of daily truncations is around 10, which consistently occurs in August.

[aekiss]

OK that makes sense. If the truncations mostly occur at the same location in Hudson Bay we should probably edit the topography there.

If we need to do a lot of this sort of editing it could be worthwhile getting editTopo.py working again COSIMA/topogtools#9

[aekiss]

It would be worthwhile inspecting the GEBCO bathymetry in that location to decide how to edit the topography, e.g. like we did here.

[adele-morrison]

Maybe comparing to the GFDL OM5 bathymetry in Hudson Bay would be helpful?

[aekiss]

Could also compare to the original OM2 bathymetry

[ezhilsabareesh8]

I apologise for the delay in getting back to this issue. I was occupied with the truncation file issue and wanted to confirm that the truncations are indeed happening at Hudson Bay, and they are consistent with the hourly output. I’ve opened an issue to report the bug in MOM6 regarding the truncation files NOAA-GFDL/MOM6 Issue #736.

The truncations are happening at a cell in Hudson Bay with a depth of 20m in the new topography. In the GEBCO dataset, this area is 100m deep, whereas in the OM2 topography, the strait is closed. Given our discussion during the meeting, we agreed to close it.

New Topography:

GEBCO 2024:

OM2:

If changing MAXTRUNC changes the solution, we should open an issue in https://github.com/mom-ocean/MOM6

@gustavo-marques, Changing MAXTRUNC isn't affecting the solution

[ezhilsabareesh8]

@aekiss As mentioned in the previous posts, In the new bathymetry, the depth at the crashing location is around 20m, while it's 100m in GEBCO 2024. I also noticed that Hudson's Bay is removed in the OM2 bathymetry—why was this done, and how can I replicate it?

Would deepening the 20m strait to match GEBCO 2024 help? Also, the test run with 75 vertical levels crashed at the same location due to truncation errors, just like with 50 levels.

[AndyHoggANU]

It was probably done because that area created instabilities, but not sure that was documented at the time.
I would suggest trying both options - deepen to 100m, but my suspicion is that won't solve the problem, in which case you should also try a case where the channel has a few grid points of land to block it off.

[aekiss]

Looks like the narrowness of the channel meant the gridcell-average of GEBCO was reduced to 20m by including regions of land. You could try increasing to 100m, but this is probably an unimportant channel (unless it carries a lot of runoff) so could be filled in.

[aekiss]

The OM2 topo includes Hudson Bay - I guess you meant Foxe Basin, north of Hudson Bay?

[aekiss]

More importantly, it looks like the new topography is missing these seas which are present in OM2:

• Mediterranean Sea
• Red Sea
• Baltic Sea
• Black Sea

I guess deseas is removing them?

These straits might also need opening:

• Malacca Strait
• Sunda Strait

It would be a good idea to plot the land mask difference from OM2 to spot any others, particularly in the Indonesian Archipelago.

[aekiss]

Would also be a good idea to plot the range of wet cell sizes and choose the land mask to eliminate excessively small cells, e.g. Gulf of Ob - see https://github.com/COSIMA/ACCESS-OM2-1-025-010deg-report/blob/master/figures/grid/grid.ipynb

[aekiss]

These edits would be most easily and reproducibly done with editTopo.py, so this bug should be fixed COSIMA/topogtools#9

[ofa001]

Hudson Bay or Foxe Basin area its in north might have been adjusted as it is close to the tri-pole, but yes we need Red Sea, and Gulf, Black Sea is a tricky one depending on resolution as the link to Med is through a very narrow strait.

[anton-seaice]

Looks like the narrowness of the channel meant the gridcell-average of GEBCO was reduced to 20m by including regions of land.

This is slightly worrying non? Like the topo generation should be robust to this and only look at ocean cells ?

I had a quick look in gen_topo, but it would take some more time to figure out if it has awareness of land masks.

[aekiss]

@ezhilsabareesh8 I've fixed editTopo.py so we can use that for hand-edits.

[ezhilsabareesh8]

@ezhilsabareesh8 I've fixed editTopo.py so we can use that for hand-edits.

Thanks @aekiss, I will try to do the hand edits at crash locations.

More importantly, it looks like the new topography is missing these seas which are present in OM2:

• Mediterranean Sea
• Red Sea
• Baltic Sea
• Black Sea

I guess deseas is removing them?

Yes deseas is removing them. Here is the topography generated without deseas, will have a look at land mask difference.

[aekiss]

The current OM2 0.25 deg topo /g/data/vk83/experiments/inputs/access-om2/ocean/grids/bathymetry/global.025deg/2023.05.15/topog.nc was created by make_topog.sh from https://github.com/COSIMA/make_025deg_topo/blob/13c91173e37b5e02c772d22bfa352151207519e2/make_topog.sh

This uses editTopo to apply thousands of edits from topog_edits.txt before running deseas, and then applies some edits to an existing ocean_mask.nc, and then applies this to the topography. This particular sequence may be needed to retain the marginal seas.

I expect we'll want to retain many of the edits in topog_edits.txt, so that would be a good starting point.

[adele-morrison]

@aekiss are you saying we should dive straight in and deepen Denmark Strait etc now? You don’t think it’s worth having a look first to see if there’s an issue with the transport to see if it’s needed? I guess I’m optimistic some things might be improved with different model physics, and the updated GEBCO product? Perhaps at least we could check if the same edits in topog_edits.txt have also been made in the OM5 topography before diving in?

[aekiss]

It's a bit complicated. The current OM2 0.25 deg topo /g/data/vk83/experiments/inputs/access-om2/ocean/grids/bathymetry/global.025deg/2023.05.15/topog.nc was created by this script which

1. generates topography from GEBCO
2. applies 1847 cell edits from topog_edits.txt (NB: reference background topography shown in this image is the final topog.nc, not the initial one generated from GEBCO):
3. removes seas, does partial cells, sets min depth
4. Then this existing land mask /g/data/ik11/inputs/access-om2/input_20200530/mom_025deg/ocean_mask.nc (which fills in the ocean near the tripoles) is corrected south of 60S
5. The land mask is then edited using ocean_mask_edits.txt at these 20 points (NB: reference background mask shown in this image doesn't include Antarctic corrections)
6. Then, crucially, the ocean mask is applied to the topography. This fills in wet points (e.g. over large regions around the tripoles) and also creates wet points, e.g. channels (set to the minimum depth if I recall correctly). Non-advective cells are then fixed.

So the topography and land mask are modified (and modify each other) at multiple steps, with many of the largest topography changes actually being imposed via the land mask. We'll need to think about which of these changes we want to inherit into OM3. Many of the edits at straits etc are needed to correctly reproduce the depths of unresolved sills and I expect would be a better starting point than 0.25° averages of the new GEBCO. Filling in the ocean for small cells near the tripoles is also likely to be a good idea to get CFL stability with a decent timestep.

[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/19

[aekiss]

Looks like the narrowness of the channel meant the gridcell-average of GEBCO was reduced to 20m by including regions of land.

This is slightly worrying non? Like the topo generation should be robust to this and only look at ocean cells ?

I had a quick look in gen_topo, but it would take some more time to figure out if it has awareness of land masks.

@anton-seaice see COSIMA/domain-tools#38

[aekiss]

Looks like we'll need to modify deseas to avoid filling in marginal seas connected to the ocean by 1-cell-wide channels COSIMA/domain-tools#37