Use WOA2023 initial condition

[aekiss]

Our current ACCESS-OM2 initial temp and salt were from WOA2013v2. There have been two updates since then, so at some point it would be a good idea to update to WOA 2023 https://www.ncei.noaa.gov/products/world-ocean-atlas.

In OM2 we used https://github.com/COSIMA/initial_conditions_access-om2 to generate the initial condition files.
More explanation is in sec 3.6 of the ACCESS-OM2 tech report https://github.com/COSIMA/ACCESS-OM2-1-025-010deg-report. Amongst other things, this processing interpolates T and S data horizontally into the continents so there are no issues with uninitialised wet cells if the model bathymetry differs from WOA.

We'd also want to update the SST initial condition used by CICE #50 and also update the SSS restoring file #207.

[aekiss]

Noting that WOA2013v2 was used for ACCESS-OM2 (despite the existence of WOA2018 at the time) because WOA2013v2 was specified for OMIP. If there's a new OMIP we might need to go with whatever that specifies.

[aekiss]

Also WOA2013v2 has some interpolation issues COSIMA/access-om2#103

[anton-seaice]

We'd also want to update the SST initial condition used by CICE #50

Setting the initial sea-ice condition from SST doesn't work in our current config (see #50 (comment)) but we haven't investigated why.

[aekiss]

I've downloaded a subset of WOA23 to /g/data/ik11/observations/woa23.

This includes decav products for T and S which we should use for initial conditions.

@dougiesquire, @pearseb I also downloaded oxygen, nitrate, phosphate and silicate in case they are useful for WOMBAT, e.g. for initial conditions (though in ACCESS-OM2 we used a mix of different products depending on the run; e.g. 01deg_jra55v140_iaf_cycle4 used a mix of FEMIP, GLODAPv2 and restarts via https://github.com/COSIMA/input_om2-bgc/blob/5ec65b4b6/interpolate_to_access-om2.ipynb with my_choice == '01deg_jra55v140_iaf_cycle4').

[aekiss]

The initial condition and other aspects of the new OMIP protocol for CMIP7 are still being decided, but Gokhan tells me he's thinking they should go with newer products unless they have issues. So I'd guess we're more likely to be using WOA2023 than WOA2013 for OMIP7.

[aekiss]

As a first step we could have a quick check for issues with WOA2023.

We could compare the WOA2023 and WOA2013 0.25° decav T and S for January and the Boreal winter (JFM) season used for the initial condition, e.g.

• 2d histograms of WOA2023 vs WOA2013 to see if there are any systematic differences
• plot difference of WOA2023 vs WOA2013 T and S, particularly SST if we use that for CICE initial condition

And also look at 0.25° decav SSS in all months (for SSS restoring #207)

• plot difference of WOA2023 vs WOA2013 SSS
• look for spurious noise and discontinuities Noise and discontinuities in WOA access-om2#103

[aekiss]

Probably best to generate the initial condition with 75 levels for all resolutions.

We would also need to convert to conservative temperature if we choose a TEOS10-based equation of state: #20

[ezhilsabareesh8]

• 2d histograms of WOA2023 vs WOA2013 to see if there are any systematic differences

The histograms illustrate the differences between temperature and salinity fields generated from the WOA2023 and WOA2013 datasets, at a 0.25-degree resolution.

The temperature differences are relatively small, with most values clustering near zero. The mean temperature difference is 0.10265°C.

The salinity changes exhibit a broader range, with certain regions showing significant increases or decreases. The mean salinity difference is slightly negative, indicating a small decrease in salinity in WOA2023 compared to WOA2013.

The bivariate histogram shows that most of the points are close to the zero line (note the log scale), however there are outliers and there is a difference of -5 and + 7 degree celsius.

There is a significant difference in salinity around +/- 5 PSU between the two datasets.

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

[aekiss]

Noise and discontinuities are present in WOA23 temperature and salinity so we'll need to smooth these as before.

[ezhilsabareesh8]

• look for spurious noise and discontinuities

The WOA2013 salinity data exhibits noticeable discontinuities at various locations as discussed here. The plot below shows the salinity at kara sea at a depth of 15m for WOA2013 and WOA2023 datasets.

WOA2013 Salinity at Kara Sea:

WOA2023 Salinity at Kara Sea:

The WOA2013 salinity data exhibits noticeable discontinuities , particularly around longitudes 68°E to 70°E there are abrupt shifts in salinity values, approximately 2PSU. In contrast, the WOA2023 salinity data is comparatively smoother, with more gradual changes in salinity across the same range of longitudes.

However, there are discontinuities in the near-surface temperature in both WOA2013 and WOA2023 datasets.

WOA2013 near-surface temperature:

WOA2023 near-surface temperature:

[ezhilsabareesh8]

so we'll need to smooth these as before.

@aekiss There is a smoothing function in make_salt_sfc_restore.py to handle discontinuities in generating salinity restoring files, but I suspect no smoothing was applied to the WOA13v2 dataset or in the OM2 initial conditions. I also couldn't find any smoothing functions in the initial_conditions_access-om2 code. Do you think smoothing is necessary for the WOA2023 dataset, or should it be left as is?

[aekiss]

Sorry, on second thoughts I expect we can get away without smoothing the initial condition because noise and discontinuities will quickly disappear (and we didn't run into problems in ACCESS-OM2).

However the SSS restoring field (#207) should be smoothed to remove these issues, because it is applied throughout the model run.

[aekiss]

Thanks for plotting the histograms @ezhilsabareesh8. It would be good to see where those differences arise. If you have a moment, could you please also plot the difference of WOA2023 minus WOA2013 T and S as maps at 0, 500, 1000, 2000, 3000m depth for January (or JFM if January is not available for the deepest levels)?

[ezhilsabareesh8]

Thanks @aekiss. The plots below shows the difference between WOA2023 and WOA2013 datasets at different depths.

The main differences between the two data sets arises at 0 and 500m, are they confined to the land masks?, but the magnitude of difference is much higher than what is observed here

[aekiss]

Thanks @ezhilsabareesh8. We wouldn't expect these differences between WOA23 and WOA13 to be similar to differences between potential and conservative temperature here.

[dougiesquire]

@ezhilsabareesh8 it looks like you might be plotting a contour plot above and it's struggling to represent very localised differences. It might be better to use something like pcolormesh for the plotting here

[aekiss]

It might be clearer to avoid the land interpolation issue by plotting histograms and difference maps of T and S in the raw WOA data for January (/g/data/ik11/observations/woa23/woa23_decav_t01_04.nc
minus /g/data/ik11/observations/WOA13v2/averaged_decades/woa13_decav_t01_04v2.nc, and similarly for salinity), and JFM for >1500m (/g/data/ik11/observations/woa23/woa23_decav_t13_04.nc
minus /g/data/ik11/observations/WOA13v2/averaged_decades/woa13_decav_t13_04v2.nc, and similarly for salinity). They seem to have identical grids.

[ezhilsabareesh8]

Thanks @aekiss, the difference in the previous plot is due to the land interpolation. The histogram plots shown below are for the difference between the raw data set.

Temperature:

Salinity

[aekiss]

Thanks @ezhilsabareesh8 that all goods good to me, so I'm happy to use WOA23 for ACCESS-OM3.

Changes are generally small, but there are relatively large SSS changes in the Arctic in places where there's almost no data underpinning WOA23 (presumably due to winter sea ice cover), so those changes are unsurprising. SSS in the Gulf of Ob is increased, which might mitigate the low salinity issue we had in ACCESS-OM2 there.

[ezhilsabareesh8]

I think there is a potential bug in initial_conditions_access-om2, particularly in makeic.py.

When generating initial conditions, it appears that the day is being set incorrectly, whereas the month should be set instead. Below are the times from files generated for each month in files woa23_ts_01_mom025.nc to woa23_ts_12_mom025.nc :

[cftime.DatetimeGregorian(1, 1, 2, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 3, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 4, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 5, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 6, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 7, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 8, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 9, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 10, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 11, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 12, 0, 0, 0, 0, has_year_zero=False)]
[cftime.DatetimeGregorian(1, 1, 13, 0, 0, 0, 0, has_year_zero=False)]

The day is increasing, when it should be the month that is advancing. This is also reflected in the access-om2 initial condition file in /g/data/vk83/experiments/inputs/access-om2/ocean/initial_conditions/global.025deg/2020.10.22/ocean_temp_salt.res.nc, which shows similar dates:

[cftime.DatetimeGregorian(1, 1, 2, 0, 0, 0, 0, has_year_zero=False)]

It is the same for the initial condition in /g/data/ik11/inputs/access-om2/input_20230515_025deg_topog/mom_025deg/ocean_temp_salt.res.nc

@aekiss Is this an error in how the time variable is being handled in the makeic.py script ?, since the decade average files are fine woa23_decav_ts_{mon}_04.nc.

[anton-seaice]

@aekiss - It looks like we need to explicitly set the dates & calendar after the regrid step ?

https://github.com/COSIMA/ocean-ic/blob/dedabdbd191c42c46008b3c1548c444740907fe8/makeic.py#L69

[anton-seaice]

@aekiss - scrap that. It looks this bit of hardcoding is wrong?

https://github.com/COSIMA/ocean-regrid/blob/e3e5404807c05ec4060624dcc0773f419860c8f0/util.py#L121

i.e.

    time = f.createVariable('time', 'f8', ('time'))
    time.long_name = 'time'
    time.units = "days since {}-{}-{} 00:00:00".format(str(start_date.year).zfill(4),
                                                       str(start_date.month).zfill(2),
                                                       str(start_date.day).zfill(2))
    time.cartesian_axis = "T"
    time.calendar_type = "GREGORIAN"
    time.calendar = "GREGORIAN"

This should be months since ... and calendar_type should be "NOLEAP" (or possibly "proleptic gregorian") ?

[aekiss]

sounds good - /g/data/ik11/inputs/access-om2/input_20201102/mom_01deg/salt_sfc_restore.nc uses

	double time(time) ;
		time:long_name = "time" ;
		time:cartesian_axis = "T" ;
		time:axis = "T" ;
		time:calendar_type = "noleap" ;
		time:calendar = "noleap" ;
		time:modulo = " " ;
		time:standard_name = "time" ;
		time:climatology = "climatology_bounds" ;
		time:units = "months since 0001-01-01 00:00:00" ;

[anton-seaice]

I raised

COSIMA/initial_conditions_access-om2#6 to fix the coordinates

and

COSIMA/initial_conditions_access-om2#7 to update to WOA23

and we need to include

COSIMA/initial_conditions_access-om2#3

Can you implement these @ezhilsabareesh8 ? Well need to update the submodules of https://github.com/COSIMA/initial_conditions_access-om2 in some places. And confirm if the provenance metadata looks ok too.