E3SM-Project / e3sm_to_cmip

Tools to CMORize E3SM output
https://e3sm-to-cmip.readthedocs.io/en/latest/
MIT License
7 stars 7 forks source link

Issues with handlers.yaml regarding huss and rlut variables #216

Open TonyB9000 opened 1 year ago

TonyB9000 commented 1 year ago

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

First, “huss”:

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”:

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.