Issues with handlers.yaml regarding huss and rlut variables

[TonyB9000]

I am looking at some (CMIP6) variables, whose names exist at different frequencies (huss, rlut, and pr) in the “handlers.yaml” file

First, “huss”:

• name: huss
  units: '1'
  raw_variables: [QREFHT]
  table: CMIP6_Amon.json
  unit_conversion: null
  formula: null
  positive: null
  levels: null

There is a table “CMIP6_day.json” that otherwise had the very same info (raw var = QREFHT). I may be encountering a problem, in that my processing of the CMIP6 output datasets

        Amon.huss       (obtained from native “atmos ... mon” data)
        day.huss          (obtained from native “atmos ... day” data)

expects the “handler table name” to match the native data frequency (Amon = atmos mon, day = atmos day) and there is no longer a table “CMIP6_day.json” listed to match the day generation.

From the “huss” section of CMIP6_Amon.json, and CMIP6_day.json (from https://github.com/PCMDI/cmip6-cmor-tables)

        [CMIP6_Amon.json]
    "huss": {
        "frequency": "mon",
        "modeling_realm": "atmos",
        "standard_name": "specific_humidity",
        "units": "1",
        "cell_methods": "area: time: mean",
        "cell_measures": "area: areacella",
        "long_name": "Near-Surface Specific Humidity",
        "comment": "Near-surface (usually, 2 meter) specific humidity.",
        "dimensions": "longitude latitude time height2m",
        "out_name": "huss",
        "type": "real",
        "positive": "",
        "valid_min": "",
        "valid_max": "",
        "ok_min_mean_abs": "",
        "ok_max_mean_abs": ""
    },

        [CMIP6_day.json]
    "huss": {
        "frequency": "day",
        "modeling_realm": "atmos",
        "standard_name": "specific_humidity",
        "units": "1",
        "cell_methods": "area: time: mean",
        "cell_measures": "area: areacella",
        "long_name": "Near-Surface Specific Humidity",
        "comment": "Near-surface (usually, 2 meter) specific humidity.",
        "dimensions": "longitude latitude time height2m",
        "out_name": "huss",
        "type": "real",
        "positive": "",
        "valid_min": "",
        "valid_max": "",
        "ok_min_mean_abs": "",
        "ok_max_mean_abs": ""
    },

Second: “rlut”:

• name: rlut
  units: W m-2
  raw_variables: [FLUT]
  table: CMIP6_day.json
  unit_conversion: null
  formula: FSNTOA - FSNT + FLNT <- cannot generate this from “day” native data – no FSNTOA present. Should this be FLUT (modulo units)?
  positive: up
  levels: null

• name: rlut
  units: W m-2
  raw_variables: [FSNTOA, FSNT, FLNT]
  table: CMIP6_Amon.json
  unit_conversion: null
  formula: FSNTOA - FSNT + FLNT
  positive: up
  levels: null

Note that both atmos monthly and atmos day data have a native var “FLUT”. I had run into a problem where datasm sought “info” for “rlut” (with monthly data, aiming to produce Amon output), found a handler for rlut (CMIP6_day) whose raw variable “FLUT” was indeed in the monthly data, and used that handler instead of the (assumed correct) Amon handler formula. So, it passed “FLUT” as the variable, along with FSNTOA, FSNT, FLNT to apply, instead of only FSNTOA, FSNT, FLNT. The regridder happily accepted the FLUT task, and the happily accepted that output.

Trying to fix this, I added the following to “run_info_mode (3)”:

                if self.freq == "mon" and handler['table'] == "CMIP6_day.json":
                    continue
                if self.freq == "day" and handler['table'] == "CMIP6_Amon.json":
                    continue

But this causes “day.huss” to fail, because there is no “CMIP6_day.json” for self.freq == "day" listed in the handlers.yaml file.