Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update SSS restoring to match WOA2023 #207

Open
aekiss opened this issue Aug 15, 2024 · 17 comments
Open

Update SSS restoring to match WOA2023 #207

aekiss opened this issue Aug 15, 2024 · 17 comments
Assignees

Comments

@aekiss
Copy link
Contributor

aekiss commented Aug 15, 2024

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 aekiss changed the title Update SSS restoring to JRA55 v1.5.0 Update SSS restoring to match WOA2023 Aug 15, 2024
@aekiss aekiss added mom6 Related to MOM6 inputs Input data labels Aug 15, 2024
@aekiss
Copy link
Contributor Author

aekiss commented Aug 21, 2024

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

@aekiss
Copy link
Contributor Author

aekiss commented Aug 21, 2024

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.

@ezhilsabareesh8 ezhilsabareesh8 self-assigned this Aug 21, 2024
@aekiss
Copy link
Contributor Author

aekiss commented Aug 21, 2024

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
Copy link
Contributor

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
Copy link

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
Copy link

/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
Copy link

ofa001 commented Aug 22, 2024

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
Copy link
Contributor Author

aekiss commented Aug 22, 2024

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.
Screenshot 2024-08-22 at 4 29 48 pm
Screenshot 2024-08-22 at 4 30 13 pm
Screenshot 2024-08-22 at 4 30 21 pm

@adele-morrison
Copy link

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
Copy link
Contributor Author

aekiss commented Aug 22, 2024

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
Copy link
Contributor Author

aekiss commented Aug 22, 2024

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
Copy link
Contributor Author

aekiss commented Aug 23, 2024

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
Copy link
Contributor

@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:
Screenshot 2024-08-27 at 4 42 33 pm

New salt_sfc_restore:
Screenshot 2024-08-27 at 4 30 55 pm

Difference:
Screenshot 2024-08-27 at 4 30 59 pm

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
Copy link
Contributor

ezhilsabareesh8 commented Aug 28, 2024

With the land mask applied:

OM2 salt_sfc_restore:

Screenshot 2024-08-28 at 2 21 03 pm

New salt_sfc_restore:

Screenshot 2024-08-28 at 2 20 59 pm

Difference:

Screenshot 2024-08-28 at 2 24 05 pm

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):

Screenshot 2024-08-28 at 4 39 10 pm

woa13_ts_01_mom025.nc on new grid:

Screenshot 2024-08-28 at 4 49 43 pm

woa23_ts_01_mom025.nc on new grid:

Screenshot 2024-08-28 at 4 41 55 pm

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
Copy link
Collaborator

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

@AndyHoggANU
Copy link

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
Copy link
Contributor

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

Check_salt_sfc_restore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants