RC for MGOHCTA

[Darwyn72]

If you are registering content (RC) for obs4MIPs, please fill out the requested information below. If you want to create an issue about something else, please delete the text below and title your issue as appropriate.

To register (or edit) some or all of the obs4MIPs RC, please title this github issue as follows:
"RC for " + your source_name (as you define below), and indicate if you are modifying your input from an earlier issue

---

The following are required registered content (with example content for each item in bold). Please replace the example text below with your information to the right of the equal sign (DO NOT MAKE ANY CHANGES TO THE LEFT HAND SIDE OF THE EQUAL SIGN):

1. source_id['source_id'][key]['source_name'] = 'MGOHCTA'
2. source_id['source_id'][key]['release_year'] = '2024'
3. source_id['source_id'][key]['source_description'] = 'Monthly Global Ocean Heat Content and Temperature Anomalies in-situ (gridded)'
4. source_id['source_id'][key]['source_version_number'] = 'WOA09'
5. source_id['source_id'][key]['institution_id'] = 'NOAA-NCEI'
6. source_id['source_id'][key]['region'] = 'global_ocean'
7. source_id['source_id'][key]['source_type'] = 'gridded_insitu'
8. A list of CMIP variable_ids that the above information refers to. In most cases it will only be for one variable_id. If it is for more than one, please make sure your source_description is sufficiently general to apply to all relevant variable_ids.
   ocean_heat_content = ohc (joulesE22)

---

See note 14 and Appendix II of the obs4MIPs data specifications (https://goo.gl/jVZsQl) for more information regarding registered content, and feel free to ask questions!

[Darwyn72]

@gleckler1 @durack1 @taylor13 I could not find a suitable variable_id for this data, as its given as ocean heat content measured in 10^22 Joules. Could we use a new name like 'ohc' or to align with CMIP CV's, something like 'hct' ?

[durack1]

This is a common quantity, but we don't have an associated CF standard name registered, yet, see http://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html. I would also assume that units of J m-2 would be most aligned to other CF variables.

As this is a derived quantity, which we are not requesting from models in CMIP7 (I don't think), maybe targeting the thetao equivalent is a better path (but WOA/NOAA doesn't produce this).

I'd also note the "WOA10" identifier looks wrong to me, the WOA expands to World Ocean Atlas, and 23 (2023) is the latest release. To make a tangle a little trickier, according to the webpage, they are still using a WOA09 climatological fields from which to base the 2024/25 anomalies - https://www.ncei.noaa.gov/products/ocean-heat-salt-sea-level. This definitely needs a little thinking, and a fair amount of metadata to define what the data actually is

Edit: @taylor13 rightly pointed out that the two variables phcint (sea_water_potential_temperature_expressed_as_heat_content) and chcint (sea_water_conservative_temperature_expressed_as_heat_content) are included in the CMIP7 data request, see #425 (comment). We do in fact have CF standard names integral_wrt_depth_of_sea_water_conservative_temperature_expressed_as_heat_content along with the potential temperature variant defined as well

[gleckler1]

@Darwyn72 @durack1 @taylor13 Recalling recent discussions about OHC vs thetao in obs4MIPs. Paul to we have a pointer to the data from the proposal? I continue to think thetao is the more appropriate quantity for obs4MIPs than OHC - users can then derive observed and simulated OHC consistently.

[Darwyn72]

@gleckler1 The link in the .JSON I am preparing seem to be broken! It no longer points to anything. I do have a copy of the .nc file that it pointed to though. I've check it in a jupyter notebook and I don't understand the output. It seems to be only 20 values (annualised) on a lat/lon grid for whole ocean an then split up into different regions. I can piut a screen dump of the variables below. The NOAA page with the relevant information is here https://www.ncei.noaa.gov/access/global-ocean-heat-content/index.html#ShowNote but I am not sure where the data is now - maybe here https://www.nodc.noaa.gov/OC5/indprod.html thetao is sea_water_potential_temperature in degC, so this would mean a conversion...

[Darwyn72]

@gleckler1 here is the ds.variables print (shortened) from the file I had listed in the obs4MIPs proposal #57, although that linbk no-longer works, so I've updated the proposal. It might be that this dataset is not actually valuable. I can forward the .nc file to you if you want to have a look.

{'crs': <class 'netCDF4._netCDF4.Variable'>
int32 crs()
grid_mapping_name: latitude_longitude
epsg_code: EPSG:4326
longitude_of_prime_meridian: 0.0
semi_major_axis: 6378137.0
inverse_flattening: 298.25723
unlimited dimensions:
current shape = ()
filling on, default _FillValue of -2147483647 used, 'lat': <class 'netCDF4._netCDF4.Variable'>
float32 lat(lat)
standard_name: latitude
long_name: latitude
units: degrees_north
axis: Y
bounds: lat_bnds
unlimited dimensions:
current shape = (180,)
filling on, default _FillValue of 9.969209968386869e+36 used, 'lat_bnds': <class 'netCDF4._netCDF4.Variable'>
float32 lat_bnds(lat, nbounds)
comment: latitude bounds
unlimited dimensions:
current shape = (180, 2)
filling on, default _FillValue of 9.969209968386869e+36 used, 'lon': <class 'netCDF4._netCDF4.Variable'>
float32 lon(lon)
standard_name: longitude
long_name: longitude
units: degrees_east
axis: X
bounds: lon_bnds
unlimited dimensions:
current shape = (360,)
filling on, default _FillValue of 9.969209968386869e+36 used, 'lon_bnds': <class 'netCDF4._netCDF4.Variable'>
float32 lon_bnds(lon, nbounds)
comment: longitude bounds
unlimited dimensions:
current shape = (360, 2)
filling on, default _FillValue of 9.969209968386869e+36 used, 'depth_bnds': <class 'netCDF4._netCDF4.Variable'>
float32 depth_bnds(depth, nbounds)
comment: depth bounds
positive: down
units: meters
axis: Z
unlimited dimensions:
current shape = (1, 2)
filling on, default _FillValue of 9.969209968386869e+36 used, 'time': <class 'netCDF4._netCDF4.Variable'>
float32 time(time)
standard_name: time
long_name: time
units: months since 1955-01-01 00:00:00
axis: T
climatology: climatology_bounds
unlimited dimensions:
current shape = (20,)
filling on, default _FillValue of 9.969209968386869e+36 used, 'climatology_bounds': <class 'netCDF4._netCDF4.Variable'>
float32 climatology_bounds(time, nbounds)
comment: This variable defines the bounds of the climatological time period for each time
unlimited dimensions:
current shape = (20, 2)
filling on, default _FillValue of 9.969209968386869e+36 used, 'h18_hc': <class 'netCDF4._netCDF4.Variable'>
float32 h18_hc(time, depth, lat, lon)
long_name: Ocean heat content anomaly calculated from objectively analyzed temperature anomaly fields over given depth limits
coordinates: time lat lon depth
cell_methods: area: mean depth: mean time: mean
grid_mapping: crs
units: 10^18_joules
_FillValue: 9.96921e+36
unlimited dimensions:
current shape = (20, 1, 180, 360)
filling on, 'yearl_h22_WO': <class 'netCDF4._netCDF4.Variable'>
float32 yearl_h22_WO(time)
long_name: global_heat_content_integral_0-2000
units: 10^22_joules
unlimited dimensions:
current shape = (20,)
filling on, default _FillValue of 9.969209968386869e+36 used, 'yearl_h22_se_WO': <class 'netCDF4._netCDF4.Variable'>
float32 yearl_h22_se_WO(time)
long_name: global_standarderror_heat_content_integral_0-2000
units: 10^22_joules
unlimited dimensions:
current shape = (20,)
filling on, default _FillValue of 9.969209968386869e+36 used, 'yearl_h22_NH': <class 'netCDF4._netCDF4.Variable'>
float32 yearl_h22_NH(time)
long_name: northern_hemisphere_heat_content_integral_0-2000
units: 10^22_joules
unlimited dimensions:
current shape = (20,)
filling on, default _FillValue of 9.969209968386869e+36 used, 'yearl_h22_se_NH': <class 'netCDF4._netCDF4.Variable'>
float32 yearl_h22_se_NH(time)
long_name: northern_hemisphere_standarderror_heat_content_integral_0-2000
units: 10^22_joules
unlimited dimensions:
current shape = (20,)................

filling on, default _FillValue of 9.969209968386869e+36 used, 'basin_mask': <class 'netCDF4._netCDF4.Variable'>
int32 basin_mask(lat, lon)
long_name: basin mask
_FillValue: -100
grid_mapping: crs
flag_values: Not_used_in_Basin_Integrals Atlantic_Basin Pacific_Basin Indian_Basin
comment: For North Hem. use Lats 0.5 to 89.5 For South use Lats -89.5 to -0.5
unlimited dimensions:
current shape = (180, 360)
filling on}

[gleckler1]

@Darwyn72 @durack1 @taylor13 OK, I see the source @ncei now, and I have examined the actual data available which are domain averages (basin and depth), i.e., not a gridded product. I am much more comfortable with that! So yes, these data can included, but doing this properly is going to take work and special attention given that a "basin" string should be included (we now have an example on how to do that but this is NEW for obs4MIPs), also they are anomaly time series (we are able to accommodate that too but it is also NEW! @Kate-Willett). This is a rare circumstance with some uncertainties estimates are available, so that too could be explored. Given the complexities here it is especially important that the person who is going to prepare these data engage with us in the process. Is the person who will do the work identified in the proposal or are they one in the same?

[Darwyn72]

@gleckler1 I put this proposal through for Dora as a potential back-up REF dataset, so let me check if I need to prepare it. I've started the .JSON on a branch and was intending to organise the .py script. In which case, I would need to use your zonal means demo as a starting point.

[gleckler1]

@Darwyn72 not zonal means demo but global mean demo which is on my to do list. This will give me a nudge.

[dhegedus99]

@gleckler1 @Darwyn72 has a source_id been decided for this dataset?

[gleckler1]

@Darwyn72 yes, there is one now, but we may iterate on this some as there are multiple new specs here...

[gleckler1]

@Darwyn72 ok source_id is in master, and a prototype new name in the OMon table, ohcanom ... the dimensions of this are something like (basin, olevel, time) .... I don't see a CMIP6 variable with these dimensions, that is ok, but I expect this is going to require some experimentation with CMOR as both the basin and olevel require a close eye.