Non CF compliant standard names for ocean transport diagnostics

[aidanheerdegen]

The standard names for T-cell mass transport are not CF compliant:

MOM5/src/mom5/ocean_diag/ocean_adv_vel_diag.F90

Lines 231 to 238 in 9f5866b

	id_tx_trans = register_diag_field ('ocean_model','tx_trans', Grd%tracer_axes_flux_x(1:3),&
	Time%model_time, 'T-cell i-mass transport',trim(transport_dims), &
	missing_value=missing_value, range=(/-1e20,1e20/), &
	standard_name='ocean_x_mass_transport')
	id_ty_trans = register_diag_field ('ocean_model','ty_trans', Grd%tracer_axes_flux_y(1:3), &
	Time%model_time, 'T-cell j-mass transport',trim(transport_dims), &
	missing_value=missing_value, range=(/-1e20,1e20/), &
	standard_name='ocean_y_mass_transport')

According to this

http://cfconventions.org/Data/cf-standard-names/28/build/cf-standard-name-table.html

ocean_x_mass_transport should be ocean_mass_x_transport
ocean_y_mass_transport should be ocean_mass_y_transport

[aidanheerdegen]

These also seem to be non-standard standard_names

icemelt_flux
iceform_flux
salt_variance
global_salinity_variance
global_temperature_variance
temperature_variance
temperature_flux_due_to_evaporation_expressed_as_heat_flux_into_sea_water

[aidanheerdegen]

Generated above list from a list of MOM diagnostics (https://github.com/COSIMA/access-om2/blob/master/MOM_diags.txt) like so:

cat MOM_diags.txt | sed -r -n "s/.*standard_name\s*=\s*'(\S*)'.*/\1/p" > MOM_cf_standard_names

and then ran that through:

import xml.etree.ElementTree as ET

tree = ET.parse('cf-standard-name-table.xml')
root = tree.getroot()

names = set()

for child in root:
    if 'id' in child.attrib:
        names.add(child.attrib["id"])

mom_names = set(open('MOM_cf_standard_names').read().splitlines())

missing = mom_names.difference(names)

for v in missing:
    print(v)

[StephenGriffies]

Good catches @aidanheerdegen .

I suggest modifying the names to be CF compliant, unless there are any backward compatibility needs/desires.

[marshallward]

MOM6 has some code to support both CF and legacy names, might be worth a look. For the most part it's a wrapper around register_diag_field -> register_diag_field_expand_cmor before it enters FMS.

https://github.com/NOAA-GFDL/MOM6/blob/dev/gfdl/src/framework/MOM_diag_mediator.F90#L1810

Doubt it's worth adopting wholemeal, but the idea might be useful.

[aidanheerdegen]

Neat. I also notice it is logging available diagnostics. This is something I've been thinking about for quite some time. I was thinking to add it to FMS and do a PR after we separate FMS out of the main codebase

https://github.com/NOAA-GFDL/MOM6/blob/dev/gfdl/src/framework/MOM_diag_mediator.F90#L3332-L3363

[aidanheerdegen]

So there aren't many CMOR supported variables, at least from the diag listings I found lying about

"ocean_model", "Ahh"  [Unused] (CMOR equivalent is "difmxybo")
"ocean_model", "Ahh_xyave"  [Unused] (CMOR equivalent is "difmxybo_xyave")
"ocean_model_z", "Ahh"  [Unused] (CMOR equivalent is "difmxybo")
"ocean_model_z", "Ahh_xyave"  [Unused] (CMOR equivalent is "difmxybo_xyave")
"ocean_model", "FrictWorkIntz"  [Unused] (CMOR equivalent is "dispkexyfo")
"ocean_model", "GMwork"  [Unused] (CMOR equivalent is "tnkebto")
"ocean_model", "KHTH_t"  [Unused] (CMOR equivalent is "diftrblo")
"ocean_model", "KHTH_t_xyave"  [Unused] (CMOR equivalent is "diftrblo_xyave")
"ocean_model_z", "KHTH_t"  [Unused] (CMOR equivalent is "diftrblo")
"ocean_model_z", "KHTH_t_xyave"  [Unused] (CMOR equivalent is "diftrblo_xyave")
"ocean_model", "u"  [Used] (CMOR equivalent is "uo")
"ocean_model", "u_xyave"  [Unused] (CMOR equivalent is "uo_xyave")
"ocean_model_z", "u"  [Unused] (CMOR equivalent is "uo")
"ocean_model_z", "u_xyave"  [Unused] (CMOR equivalent is "uo_xyave")
"ocean_model", "v"  [Used] (CMOR equivalent is "vo")
"ocean_model", "v_xyave"  [Unused] (CMOR equivalent is "vo_xyave")
"ocean_model_z", "v"  [Unused] (CMOR equivalent is "vo")
"ocean_model_z", "v_xyave"  [Unused] (CMOR equivalent is "vo_xyave")
"ocean_model", "KHTR_h"  [Unused] (CMOR equivalent is "diftrelo")
"ocean_model", "taux"  [Unused] (CMOR equivalent is "tauuo")
"ocean_model", "tauy"  [Unused] (CMOR equivalent is "tauvo")
"ocean_model", "p_surf"  [Unused] (CMOR equivalent is "pso")

I can see MOM6 makes a lot of use of this derived diagnostic stuff to allow more straightforward output of z-grid interpolated fields and such.

I agree @StephenGriffies that the two variables I highlighted first should be changed to reflect the correct standard_name. The others I am unsure about. For example, temperature_flux_due_to_evaporation_expressed_as_heat_flux_into_sea_water is not a valid CF standard name, but temperature_flux_due_to_rainfall_expressed_as_heat_flux_into_sea_water is, and so I assume the former was based on the latter when the diagnostic was encoded.

The others seem to not correspond closely to any CF diagnostic. I will leave them for the time being.

[StephenGriffies]

The MOM5 diagnostics were written largely around 2012 or before. The CMIP6 names, however, evolved afterwards. So there will be many holes and inconsistencies.

I suspect the CSIRO did some of the leg-work as part of CMIP6. Perhaps they developed a diag_table with MOM5 names and the corresponding CMIP6/CF names. If given that translation, then it would be a straightforward job to update the CF names in MOM5 to correspond to CMIP6.

[aidanheerdegen]

The two variables I have just changed in the pull request were picked up in a QC check by NCI data folks. No other variables were highlighted in their checks.

The check I did above is not exhaustive, but it certainly captures every diagnostic with a standard_name argument, and the only mismatches are detailed above. It may be there are diagnostics that do not currently have a standard_name that one could be added. As you say CSIRO may have that information for the CMIP6 processing toolchain. I will enquire, but I'll merge the above PR now and leave that for another pull request.

[durack1]

@aidanheerdegen @StephenGriffies just FYI, the CMIP6 diagnostics are listed in either the data request (http://clipc-services.ceda.ac.uk/dreq/index.html) or the cmip6-cmor-tables (cmip6-cmor-tables) which is used by CMOR. This is the complete exhaustive list of CMIP6 variables requested (and their names etc), which has expanded considerably from cmip5 (which was documented in the cmip5-cmor-tables)

[aidanheerdegen]

Thanks @durack1