Followup re: AGU discussion and model idiosyncrasies

[tsjackson-noaa]

I'm starting this thread to build on interesting remarks made by @andrewgettelman and @jkrasting in the discussion following the MDTF session at the 2020 AGU fall meeting. In particular, Andrew was talking about how idiosyncrasies in model output conventions were an obstacle in the work he's done on model intercomparison -- this is referring not to the model's native output format, but the meaning of its output, e.g. how "olr" could refer to "top of atmosphere" in one model and "top of model" in another.

These sorts of miscommunications could be especially relevant for us, since the MDTF package already has a foot in both the weather/high-frequency diagnostics and climatology communities (as John mentioned), and we're looking to extend to other sub-fields. I'm at a bit of a loss as to how we could tackle this issue systematically, though -- one option might be to develop a controlled vocabulary that's much more granular than the CF convention standard names (that would eg distinguish between top of atmosphere/top of model) and map each models' native variables to this finer classification.

Andrew mentioned that he had compiled a list of similar model-specific "known issues"/"special cases" encountered during his work with CCSM (at least according to my incomplete notes from the session) -- it would be instructive to look at this in more detail and start thinking about how it could be incorporated into the package.

[jkrasting]

Nice topic to discuss, @tsjackson-noaa.

The ocean community has handled this by creating separate variables to distinguish these differences. One example from @StephenGriffies et al 2016. GMDD is that Table 11 contains vector fields defined on both native and Earth-relative grids. The mass streamfunction defined relative to latitude is msftmyz while the same field defined relative to the grid is msftyyz.

Given the importance and prevalence of CF conventions in the community, I'd love to hear @gleckler1's and @durack1's thoughts on this from the PCMDI perspective.

[andrewgettelman]

What I envisioned was based on work we did for the CCMVal Tool, which was incorporated into the ESMVal tool. It's a mechanism for 'fixing' the data to conform to the tool conventions (usually CF compliant output and metadata). It is variable specific, but I think is easy to customize.

https://docs.esmvaltool.org/projects/esmvalcore/en/latest/develop/fixing_data.html#fixing-data

This page describes the API for fixing data: you can write python code to modify files/variables as needed. Something like that (maybe simpler) could be implemented for each model (NCAR, GFDL), and for new variables. This could adjust OLR from Top of Model to Top of Atmosphere.

[tsjackson-noaa]

Thanks for the details, @andrewgettelman -- I'm still digesting the info in the link you posted.

This post is to document a more concrete aspect of this general problem: limitations of the CF convention standard names. We've hit this in two places already:

• The example POD uses near-surface air temperature data (CMIP6 tas, defined at a 2m reference altitude). This choice was totally arbitrary: we only need a variable that's i) familiar and ii) intrinsically has no Z dependence, to minimize the amount of data needed to be downloaded. (We should include iii) is commonly included in model output, which would disqualify tas).

  At any rate, despite being part of the CMIP6 data request (eg in the Amon table), there's no standard name for this variable. In this case the simplest resolution would be to request ts, surface_temperature, instead. It's not clear to me what the practical distinction is.

• CAM natively expresses precipitation (PRECT) as a rate, and some of the NCL-based PODs assume these units explicitly or implicitly. The CF conventions don't include precipitation_rate, only precipitation_flux, although they do include both convective_precipitation_rate and convective_precipitation_flux. CAM also defines the complement of that, PRECL ("Large-scale (stable) precipitation rate"), but there are no CF names to distinguish resolved from parameterized quantities.

  Conversion between precip rates and fluxes is currently handled as a special case of unit conversion; see tsjackson-noaa/MDTF-diagnostics@928f054.

The upshot is simply that we can't rely solely on the CF conventions to provide a dictionary to translate between native model data formats. The long-term solution will be to "CMORize on the fly," as described in the ESMValTool docs linked by Andrew above.