COSIMA / access-om3

ACCESS-OM3 global ocean-sea ice-wave coupled model
13 stars 7 forks source link

Use WOA2023 initial condition #161

Open aekiss opened 6 months ago

aekiss commented 6 months ago

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 https://github.com/COSIMA/access-om3/issues/50 and also update the SSS restoring file https://github.com/COSIMA/access-om3/issues/207.

aekiss commented 4 months ago

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 commented 4 months ago

Also WOA2013v2 has some interpolation issues https://github.com/COSIMA/access-om2/issues/103

anton-seaice commented 4 months ago

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 https://github.com/COSIMA/access-om3/issues/50#issuecomment-2019558853) but we haven't investigated why.

aekiss commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.

And also look at 0.25° decav SSS in all months (for SSS restoring https://github.com/COSIMA/access-om3/issues/207)

aekiss commented 3 months ago

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: https://github.com/COSIMA/access-om3/issues/20

ezhilsabareesh8 commented 3 months ago
  • 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.

025 deg_temp_histogram

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

025 deg_salt_histogram

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.

025 deg_temp_bivariate_histogram

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.

025 deg_salt_bivariate_histogram

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

access-hive-bot commented 3 months ago

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 commented 3 months ago

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

ezhilsabareesh8 commented 3 months ago
  • look for spurious noise and discontinuities
Screenshot 2024-08-20 at 4 16 24 pm

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:

Screenshot 2024-08-20 at 2 51 47 pm Screenshot 2024-08-20 at 3 15 16 pm

WOA2023 Salinity at Kara Sea:

Screenshot 2024-08-20 at 4 13 23 pm WOA_2023_salinity

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:

Screenshot 2024-08-20 at 3 41 28 pm WOA2013_TEMP

WOA2023 near-surface temperature:

Screenshot 2024-08-21 at 2 10 12 pm Screenshot 2024-08-20 at 4 38 27 pm
ezhilsabareesh8 commented 3 months ago

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 commented 3 months ago

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 (https://github.com/COSIMA/access-om3/issues/207) should be smoothed to remove these issues, because it is applied throughout the model run.

aekiss commented 3 months ago

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 commented 3 months ago

Thanks @aekiss. The plots below shows the difference between WOA2023 and WOA2013 datasets at different depths. 025 deg_temp_depth_0 025 deg_temp_depth_500 025 deg_temp_depth_1000 025 deg_temp_depth_3000

025 deg_salt_depth_0 025 deg_salt_depth_500 025 deg_salt_depth_1000 025 deg_salt_depth_3000

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 commented 3 months ago

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

dougiesquire commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

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: 025 deg_t_an_histogram

025 deg_t_an_bivariate_histogram

025 deg_t_an_depth_0 025 deg_t_an_depth_500 025 deg_t_an_depth_1000 025 deg_t_an_depth_3000

Salinity 025 deg_s_an_histogram 025 deg_s_an_bivariate_histogram 025 deg_s_an_depth_0 025 deg_s_an_depth_500 025 deg_s_an_depth_1000 025 deg_s_an_depth_3000

aekiss commented 3 months ago

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 commented 2 months ago

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 commented 1 month ago

@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 commented 1 month ago

@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 commented 1 month ago

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 commented 1 month ago

I raised

https://github.com/COSIMA/initial_conditions_access-om2/issues/6 to fix the coordinates

and

https://github.com/COSIMA/initial_conditions_access-om2/issues/7 to update to WOA23

and we need to include

https://github.com/COSIMA/initial_conditions_access-om2/issues/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.