POD discussion: CPT metrics

[tsjackson-noaa]

The following notes provide further background on issues Zun Yin encountered. These are from my own notes, so apologies if I've misunderstood the issues raised.
In addition, we strongly recommend using xarray to handle input data, since it has some support for CF conventions which simplifies dealing with some of the issues mentioned. It's reasonable to design a POD assuming its input data will be CF-compliant.

• Issues that are addressable in the current code:
  There are ways to accomplish some of the issues you brought up in the current release of the code (officially v3 beta 2, but you should use the main branch instead). As an example, I'd suggest looking at the settings file for the convective transition diagnostics POD, with the caveat that the format of this file will be changed in the upcoming release (see below).

  • Optional model input variables: the example given was using the dew point temperature if provided in the model output, or computing it from more fundamental variables if not. This is implemented by the "alternates" specification in the settings file variable list ("varlist"): you'd add an entry for dew point temperature which would list entries for temperature, pressure and humidity as alternates. If the package doesn't find model output for dew point temperature, it will look for the alternate variables. If it can't find those, the POD won't run.
  • User-configurable POD settings: Another issue is allowing the user to switch between, e.g., different observational data resolutions, or switching between a "quick" and "extended" mode of operation. This is currently addressed by allowing PODs to define arbitrary environment variables in their settings file, as is done in the convective transition example, where the user has the option to say that they've downloaded higher resolution observational data.

• Addressed in upcoming release (v3 beta 3):
  We're working on a new release that addresses some of the other issues. It involves a more detailed setting file format, described in the documentation, which all new diagnostics should use. As an example, compare the settings file for the convective transition diagnostics in the new format.

  • Model data naming convention: the new code will rename variables and coordinates as requested. The full path to each input file will be set in an environment variable, so PODs won't need to deduce this path, test for file existence, etc.
  • Model data unit conversion: the new settings file format requires you to specify the units of all input variables, and will convert input model data to these units if necessary before calling your POD. Any units and unit conversions recognized by the UDUnits2 library are supported.

• Possible feature requests:
  The following issues aren't addressed by currently written code. If they're major obstacles to writing your POD, you should advocate for them by opening a feature request (as a github issue).

  • Z axis conversion: this is a high-priority feature for the release after beta 3, due to the need to support the hybrid sigma coordinate used natively by NCAR's models. For the present, your POD should assume that the vertical coordinate for all variables is air pressure, request geopotential height and/or orography as additional variables, and do any necessary conversion internally.
  • Time axis conversion: converting from model's convention to local time was suggested. Currently this should be handled internally by the POD.
  • Allowing users to pass options to PODs from the command line, which could make things more manageable for users than needing to manually edit the POD's settings file.