Update SSS restoring to match WOA2023

[aekiss]

When/if we update the initial condition to WOA2023 (#161) we should update the sea surface salinity restoring file to be based on the same dataset, using https://github.com/COSIMA/access-om2/blob/master/tools/make_salt_sfc_restore.py

We should also set parameters to match whatever the CMIP7 OMIP specifies (https://oceanmip.github.io/).

See section 3.5.2 of the ACCESS-OM2 tech report.

Related: #51, #66

[aekiss]

Noise and discontinuities are present in WOA23 salinity so we'll need to smooth it.

[aekiss]

I've made a PR (COSIMA/om3-scripts#24) to copy https://github.com/COSIMA/access-om2/blob/master/tools/make_salt_sfc_restore.py into om3-scripts, as we need to update it, e.g. to provide provenance.

[aekiss]

make_salt_sfc_restore.py uses /g/data1/v45/aph502/jra55/sss/mean_salinity_of_0_and_10m.nc which no longer exists - @aidanheerdegen do recall how this was created? presumably nco?

[ezhilsabareesh8]

Here's a relevant comment that addresses how /g/data1/v45/aph502/jra55/sss/mean_salinity_of_0_and_10m.nc was generated. It was derived from /g/data/v45/akm157/data/WOA13v2/averaged_decades/woa13_decav_sss_clim_04v2_0m_10m.nc, which @adele-morrison created by averaging 0m and 10m data from WOA13v2. @adele-morrison Do you know how this file was created? I'm looking for any additional details you might have.

[adele-morrison]

What's the justification for using the mean of 0m and 10m? Was that because we used to have coarse vertical resolution, with the depth of the upper cell about 10m? If so, does it make more sense just to use 0m now?

[adele-morrison]

/g/data/v45/akm157/data/WOA13v2/averaged_decades/woa13_decav_sss_clim_04v2_0m_10m.nc was created as follows:

# paths
data_dir = '/g/data/v45/akm157/data/WOA13v2/averaged_decades/'

# 0m file:
woa_file = data_dir+'woa13_decav_sss_clim_04v2_0m.nc'
ncFile = nc.Dataset(woa_file)
s_an_0m = ncFile.variables['s_an'][...]

# 10m file:
woa_file = data_dir+'woa13_decav_sss_clim_04v2_10m.nc'
ncFile = nc.Dataset(woa_file)
s_an_10m = ncFile.variables['s_an'][...]

# average:
s_an_0_10m = (s_an_0m + s_an_10m)/2

[ofa001]

Hi @adele-morrison There was some strange data in the near surface salinities in the earlier WOA versions we used to initialize the ACCESS-OM (for ACCESS1-0/3 spin up ) not sure if it was still in WOA in 2013 but unless they went and eliminated them by hand. Some salinity difference between 0 and 10m them may be real. You can get diurnal salinity signals in the tropics and when ice is melting but you wouldn't really expect differences in a climatology.

[aekiss]

I suspect @adele-morrison is right that the top 10m was used because it corresponded to the old coarse vertical grid spacing.

In WOA23 the bounds are

depth_bnds =
  0, 2.5,
  2.5, 7.5,   <--- 5m data
  7.5, 12.5,  <--- 10m data
  12.5, 17.5,
  17.5, 22.5,
...

The level bottoms in ocean_vgrid with 75 levels are

 sw_ocean = 1.08256149291992, 2.27890777587891, 3.60099744796753,
    5.06204557418823, 6.67665529251099, 8.46096420288086, 10.4328050613403,
    12.6118831634521, 15.0199728012085, 17.6811332702637, 20.6219482421875, ...

so 0-10m WOA uses obs corresponding to the top 7 model levels, 0-5m covers the top 5 levels, and the top layer in WOA corresponds to the top 2 model layers, roughly speaking.

Here's the number of obs per grid cell underpinning the gridded WOA23 data in the top 3 levels. It's pretty sparse. The top layer includes surface measurements on shipping routes. The 2nd layer is significantly sparser, then the third layer is a noticeable improvement on both the others in many places, eg South Pacific. So I guess averaging these layers could somewhat reduce the interpolation errors from what you'd get with just the top level? But it could also introduce a bias in regions with shallow mixed layers.

[adele-morrison]

Maybe the average of 0 and 10m came from OMIP? If there’s more data at the surface, I’d think we’d be introducing more error by using the 10m also. And given our upper cell now has its centre around 0.5m, it seems more justified to me to use surface salinity only in the restoring field.

[aekiss]

I think I agree that the surface WOA values are the best choice for us.

OMIP didn't say anything specific about the SSS restoring - see sec 2.3 of Griffies et al., 2016:

we do not offer protocol specifications. Rather, we recommend that modellers consult Appendix C in Danabasoglu et al. (2014) to see what has worked for other models

and Danabasoglu et al. (2014) doesn't say anything specific about the SSS climatology data to restore to.

The new protocol OMIP for CMIP7 is yet to be finalised. They are considering changes to the SSS restoring protocol, but it sounds like this is focused more on the piston velocity than the dataset. So I think we're free to choose our own SSS climatology to restore to.

[aekiss]

As for which level has more data, it depends on location (eg South Pacific looks somewhat better at 10m), but the top level looks pretty good at most locations.

[aekiss]

If we're not doing vertical averaging, should we we generate salt_sfc_restore by copying and horizontally smoothing the top level (in every month) from the regridded WOA data generated by https://github.com/COSIMA/initial_conditions_access-om2 rather than using the separate script make_salt_sfc_restore.py? It would be more consistent that way.

[ezhilsabareesh8]

@aekiss I tried generating the salt_sfc_restore by copying and smoothing the top level of the regridded WOA data. I used the same smoothing function from the initial_conditions_access-om2 repo, but there are some discontinuities in the salt_sfc_restore, and the smoothing doesn’t seem to have worked properly. I’m currently digging into why this is happening and trying to figure out where things went wrong.

OM2 salt_sfc_restore:

New salt_sfc_restore:

Difference:

Also, I noticed that the time axis of the OM2 salt_sfc_restore starts from 0.5, like this:

time = 0.5, 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5, 9.5, 10.5, 11.5.

Isn't it supposed to start from 1?

[ezhilsabareesh8]

With the land mask applied:

OM2 salt_sfc_restore:

New salt_sfc_restore:

Difference:

The abnormal salinity in the Arctic appears to stem from the initial conditions, rather than the smoothing process.

OM2 woa13_ts_01_mom025.nc (from /g/data/ik11/inputs/access-om2/woa13/025):

woa13_ts_01_mom025.nc on new grid:

woa23_ts_01_mom025.nc on new grid:

We noticed in this issue, there wasn’t much difference between the WOA2013 and WOA2023 datasets, however woa13_ts_01_mom025.nc initial condition on both the old and new grid seems to be fine. I’m currently investigating this further to pinpoint the root cause.

[dougiesquire]

@ezhilsabareesh8 are you plotting with the correct (2D) lats and lons here? And are these contour plots again or pcolormesh?

[AndyHoggANU]

Yes, those arctic anomalies look like they are under land if the triple hasn't been correctly accounted for. See here:
https://github.com/COSIMA/cosima-recipes/blob/main/Tutorials/Making_Maps_with_Cartopy.ipynb

[ezhilsabareesh8]

Thank you @dougiesquire and @AndyHoggANU. The anomalies in the previous plots were due to the omission of the land mask. After fixing this, the difference between the salinity_sfc_restore in the OM2 salinity restoring and the newly generated salinity restoring file, based on the WOA2023 dataset on the new grid, shows a small discrepancy in the Arctic region, similar to what is observed in the difference between WOA2013 and WOA2023 datasets refer here