0.25 ocean mask error on W Africa coast

[MartinDix]

A CM3 run using the 0.25 topography from /g/data/tm70/ek4684/New_grid_input_files_025d eg_75zlevels (e.g. as used in runs discussed in #172) fails with extreme SSTs on the W African coast.

Comparing the mask with the OM2 version from g/data/ik11/inputs/access-om2/input_20230515_025deg_topog/mom_025deg/ocean_mask.nc shows some spurious points ocean points around 19 N

The same region in Google Earth shows an inland depression that's at or just below sea level. Is this somehow being mis-interpreted as ocean?

@ezhilsabareesh8 @kieranricardo

[kieranricardo]

@aekiss

[aekiss]

Looks like that will need some hand edits with editTopo. I'll take a look.

[aekiss]

I'm hitting this error in /g/data/tm70/ek4684/domain-tools/C-grid-workflow/fill_fraction_0.5/gen_topo.sh

cice_from_mom --ocean_hgrid ocean_hgrid.nc --ocean_mask ocean_mask.nc
/local/spool/pbs/mom_priv/jobs/132278385.gadi-pbs.SC: line 56: cice_from_mom: command not found

Where can I find cice_from_mom?

[minghangli-uni]

It is defined in the esmfgrids repo, https://github.com/COSIMA/esmgrids/blob/79f2952ca8d5961620996837e8e05c4e3d4fb469/esmgrids/cli.py#L10

[aekiss]

Thanks @minghangli-uni, what's the best way to install/access that?

[minghangli-uni]

What comes to my mind at the moment is to clone the repo, then write a wrapper to import and use it. I am not sure how Ezhil did that.

[anton-seaice]

You can just clone the esmgrids repo and then pip install it into a new venv Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: minghang.li ***@***.***> Sent: Tuesday, January 14, 2025 4:54:29 PM To: COSIMA/access-om3 ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [COSIMA/access-om3] 0.25 ocean mask error on W Africa coast (Issue #252) What comes to my mind at the moment is to clone the repo, then write a wrapper to import and use it. I am not sure how Ezhil did that. — Reply to this email directly, view it on GitHub<#252 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AS4DACGACARNWHHYZTOC53L2KSRBLAVCNFSM6AAAAABVBW4SNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOBZGA3DOOJTGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[aekiss]

Thanks @anton-seaice, that worked but now I've hit this snag COSIMA/esmgrids#21

[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-2025/4067/2

[aekiss]

@MartinDix, @kieranricardo - see how you go with the updated files in /g/data/tm70/aek156/New_grid_input_files_025deg_75zlevels_AK

They should be the same as in /g/data/tm70/ek4684/New_grid_input_files_025deg_75zlevels but with these new edits I've added to /g/data/tm70/aek156/domain-tools/C-grid-workflow/fill_fraction_0.5_AK/edit_topog_new_fillfraction.txt:

#    i    j  old                new
  1056  631  5.062045574188232  0.0
  1056  632  5.062045574188232  0.0
  1056  633  5.062045574188232  0.0
  1057  633  5.062045574188232  0.0

which fill in these 4 marked points

[aekiss]

@ezhilsabareesh8 /g/data/tm70/aek156/domain-tools/C-grid-workflow/fill_fraction_0.5_AK/ is an update to your workflow /g/data/tm70/ek4684/domain-tools/C-grid-workflow/fill_fraction_0.5/

[kieranricardo]

thanks @aekiss! This seems to do the trick - I re-ran the month that failed with the new grid and it ran successfully!

I'm also testing out a new run with this grid. I couldn't see any initial conditions in your directory @aekiss so I'm just using g/data/tm70/ek4684/New_grid_input_files_025deg_75zlevels/ocean_temp_salt.res.nc. This defines values on the newly masked out cells but it seems like this isn't a problem (if a bit hacky).

[aekiss]

Yes there's no change to the initial conditions. These have all dry points filled in with data extrapolated horizontally from the nearest ocean, so they work with any bathymetry even if new wet points are created (which isn't the case here anyway).

[MartinDix]

As well as the expected differences over Africa, there are also differences on the last (northenmost) grid row. Some sort of difference in roundoff with the tripolar?

[kieranricardo]

I've hit new excessive temperatures in the Red Sea and Persian Gulf. These areas are only a few grid cells wide at the narrowest points, how does this compare to OM2 0.25 degree?

[ofa001]

This is why we had the Red-Sea Gulf fox in ACCESS-CM2 but it was pretty basic mixing across the entrances point to point that we discussed late last year, we wondering if we should do something better for CM3.

[kieranricardo]

@ofa001 interesting, so the extra Red-Sea/Gulf mixing was necessary to get reasonable SSTs for CM2? (I thought it was just to keep the salinity under control). Was this a layer-wise averaging of water in the Red Sea/Gulf at each time step?

The SSTs don't seem to be a problem in OM3, which I think is because OM3 is calculating fluxes on the 0.25 degree grid, whereas CM3 is using UM fluxes from a ~1.5 degree grid. Maybe we could calculate fluxes on the 0.25 grid, and scale the global average to match the UM fluxes?

We'll still need some extra mixing to control the salinity though!

[aekiss]

As well as the expected differences over Africa, there are also differences on the last (northenmost) grid row. Some sort of difference in roundoff with the tripolar?

This is unexpected - I thought I'd followed @ezhilsabareesh8's workflow but maybe something had changed.

Is that the only difference in the mask? Looks like it occurs at the grid join at 80E - coincidence?

[aekiss]

The SSTs don't seem to be a problem in OM3, which I think is because OM3 is calculating fluxes on the 0.25 degree grid, whereas CM3 is using UM fluxes from a ~1.5 degree grid. Maybe we could calculate fluxes on the 0.25 grid, and scale the global average to match the UM fluxes?

Would coupling via exchange grids help? See #35 and #7

[ofa001]

HI @kieranricardo and @aekiss, I guess we did only mix for the salinities in CM2 (1 degree), but we must have mixed both the salinity and temperature of the water masses to achieve it, I will re-check. Andrew is right in terms of the fluxes though the use of an exchange grid may help though isnt 'the mediator' handling that side of things or arent their options within it to do so, so that the fluxes from UM grid and the CM3 grid at different scales are not as mismatched. ( I assume this run is 0.25 degree as its part of the earlier thread). I am not sure we needed to do additional mixing in the CM2-025 run, but we did do some adjustments to the sill depths, channel widths on a B-grid. we haven't adjusted the C-grid (Yet!).

[ofa001]

Hi @kieranricardo, yes we did only mix the volume of salt, but by implication the densities on either side of the water mixed will mix temperature if the densities are totally off in the vertical by this horizontal exchange. I think adjusting the sills and channel widths is a first step though. Depending on season the waters in the Gulf can get quite hot as they are shallow, (I have only once explored them in Dubai, Australian beaches are way better) but I suspect in the case you have additional exchange to the Indian Ocean will probably help I will have a look at what it is at the moment.

[ofa001]

Just doing a comparison with ACCESS-OM2-025, and WOA23, those points are way hotter than for those data sets, did this have the new EPBL mixing scheme on we may need to look at the parameters but one obvious observations as I started to look at the depths of the sills, the locations of those hot spots in the Gulf, Red sea nd in the Med just North of the Nile delta, are very shallow less than 6-7 grid points 7-9m, so minimal mixing, we may be getting some in the Torres St near Australia but wont be as warm as this.

[ofa001]

hi @kieranricardo Below about 15-20m there wasn't too much difference with the WOA temperatures in the Gulf Red-Sea regions with the run which was only 6 months advance presumably initialised from WOA. so its either the heat fluxes being unrealistic or low vertical mixing in shallow regions that iss causing the very high temperatures. Additional mixing at entrance wont solve it, unless they are very strong I suspect, as its happened very quickly in the run.

[ofa001]

HI @kieranricardo just compared your most recent run(20-01-25) with 16-12-24 its warmer by June of 1981 (first year) maxima in the Gulf is at a different shallow location, than the earlier one, not sure if any of the parameter settings are different like in the ocean set up. It could all be atmospheric chaos in the fluxes though for just a different run.

[MartinDix]

The CM2 namelist has redsea_gulfbay_sfix=.true. for the 1 degree configuration but false for the 0.25 degree version. The code has hardwired the region for the 1 degree grid so it would have failed anyway.
https://github.com/mom-ocean/MOM5/blob/6bdbdd4892543bbade921fa3224b2530d93c6f40/src/mom5/ocean_access/auscom_ice_parameters.F90#L46-L59

[ofa001]

Hi @MartinDix @kieranricardo just looking at our access-cm2-025 runs which had 50 levels but were actually the new 50 level set up used in access-om2 not the same as we ran in cm2 so a little more resolution in the upper 50m and in the top 10m though they didn't heat up as much in the first year. In the troublesome location in the gulf sea its actually around Qatar and Bahrain, the bah has been widened, and no isolated 1 grid point left around like we have in the C-grid set up, we must be prone to that in other regions as well, I guess we are going to have to put a filter on the topography to check, it may not be a problem in areas that are not shallow. In the red Sea it warmed up to 37C in the same location as CM3. After 400 years of the CM2 simulation the surface temperatures are in the region are in the same range as in the first year of the simulation, haven't looked if they trended up or down, during the run, but max's around 36-37C, located in Red Sea (not gulf as in the current run near Qatar).

[ofa001]

@MartinDix @kieranricardo, so I think the Qatar are is fixable, the same are in the red sea is the warmest its several degrees warmer, 44 in first year of CM3 to 35-37 in the years I checked in Cm2 the shelf is shallower by a few meters, and the 11m region is larger, perhaps of more concenn is the width and sill depth at the entrance on the C-grid its very narrower which we adjusted for CM2. Perhaps we should talk to @aekiss and @ezhilsabareesh8 when he is back from leave mid next month about making adjustments to the topography before we run again. I will look at other key CMIP6 models in the region as well like I said.

[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-2025/4067/3

[ofa001]

@kieranricardo @MartinDix @aekiss in the Hadgem-GC31-MM which is closest to what we are running, they are N216 (cf N96) 0.25 ocean Cgrid they have included more of the islands including Bahrian explicitly and some near the temperature high values we find in the Red sea, with a larger are than seen in Google maps? The area between the island and the coast is the section that traps the maximum heat in the Red Sea but at start of the "picontrol" run is 35C so way less than Cm3, Qatar region is even cooler, no heat being trapped. 11m is again shallow depth of region. even more vertical levels than in cm3 in top 10m. Arbitrary point near the end of picontrol run also has similar range of summer surface temperatures in both basins ~35-36 C.

[anton-seaice]

@aekiss - Did you use https://github.com/ACCESS-NRI/make_OM3_025deg_topo ?

Can you make a PR there with the new fillfraction.txt file please?

I will make another PR to add the rof weights generation, and then we can rerun the whole thing. It looks like the esmf-mesh files weren't updated in /g/data/tm70/aek156/domain-tools/C-grid-workflow/fill_fraction_0.5_AK ?