Summary
8 files fail the WCRP check [ATTR004] Variable '<var>' attribute 'long_name' registry expected-term check (MED, weight = 2). For 7 of the 8, the long_name
written in the file is the canonical CMIP6 value for that variable, while the
checker's expected value is the long_name of a different, sibling variable
that shares the same root name (e.g. tas → expected tasmin's string,
sfcWind → expected sfcWindmax's string, hfls → expected the ice-sheet
variant). This pattern indicates the branded-variable → registry resolution is
selecting the wrong registry entry, rather than ACCESS-MOPPy writing a wrong
long_name.
This needs triage to decide ownership: either ACCESS-MOPPy is emitting an
incorrect branded-variable identifier that resolves ambiguously, or this is an
esgvoc / cc-plugin-wcrp registry-resolution bug.
Environment
- Tool: ACCESS-MOPPy (CMORiser)
- Validator:
compliance-checker --test wcrp_cmip6:1.0 (cc-plugin-wcrp + esgvoc)
Failing Checks (verbatim)
hfls (Amon) Expected 'Ice Sheet Surface Upward Latent Heat Flux' from registry key 'long_name', got 'Surface Upward Latent Heat Flux'.
hurs (Amon) Expected 'Daily Minimum Near-Surface Relative Humidity over Crop Tile' from registry key 'long_name', got 'Near-Surface Relative Humidity'.
mrro (Lmon) Expected 'Ice Sheet Total Runoff' from registry key 'long_name', got 'Total Runoff'.
rsds (Amon) Expected 'Surface Downwelling Shortwave Radiation over Snow' from registry key 'long_name', got 'Surface Downwelling Shortwave Radiation'.
rsus (Amon) Expected 'Surface Upwelling Shortwave Radiation over Ocean Not Covered by Sea Ice' from registry key 'long_name', got 'Surface Upwelling Shortwave Radiation'.
sfcWind (Amon) Expected 'Daily Maximum Near-Surface Wind Speed' from registry key 'long_name', got 'Near-Surface Wind Speed'.
tas (Amon) Expected 'Daily Minimum Near-Surface Air Temperature' from registry key 'long_name', got 'Near-Surface Air Temperature'.
wap (Amon) Expected 'Pressure Tendency' from registry key 'long_name', got 'Omega (=dp/dt)'.
Analysis
| Variable |
Table |
File value (got) |
Checker expected |
Assessment |
| hfls |
Amon |
Surface Upward Latent Heat Flux |
Ice Sheet Surface Upward Latent Heat Flux |
File value is the canonical hfls long_name; expected belongs to the ice-sheet variant |
| hurs |
Amon |
Near-Surface Relative Humidity |
Daily Minimum Near-Surface Relative Humidity over Crop Tile |
File value is canonical hurs; expected is an unrelated daily/crop-tile variant |
| mrro |
Lmon |
Total Runoff |
Ice Sheet Total Runoff |
File value is canonical mrro; expected belongs to the ice-sheet variant |
| rsds |
Amon |
Surface Downwelling Shortwave Radiation |
Surface Downwelling Shortwave Radiation over Snow |
File value is canonical rsds; expected is the over-snow variant |
| rsus |
Amon |
Surface Upwelling Shortwave Radiation |
Surface Upwelling Shortwave Radiation over Ocean Not Covered by Sea Ice |
File value is canonical rsus; expected is the open-ocean variant |
| sfcWind |
Amon |
Near-Surface Wind Speed |
Daily Maximum Near-Surface Wind Speed |
File value is canonical sfcWind; expected belongs to sfcWindmax |
| tas |
Amon |
Near-Surface Air Temperature |
Daily Minimum Near-Surface Air Temperature |
File value is canonical tas; expected belongs to tasmin |
| wap |
Amon |
Omega (=dp/dt) |
Pressure Tendency |
File value matches the CMIP6 wap long_name; expected does not correspond to wap |
In every case the file's long_name matches the standard CMIP6 string for the
variable, and the expected value corresponds to a different variable. The
resolution appears to collapse onto a sibling branded variable that shares the
same standard root.
Although some of those reported issues are not actually valid and are caused by the checker itself, the list is mainly for our reference.
Summary
8 files fail the WCRP check
[ATTR004] Variable '<var>' attribute 'long_name' registry expected-term check(MED, weight = 2). For 7 of the 8, thelong_namewritten in the file is the canonical CMIP6 value for that variable, while the
checker's expected value is the
long_nameof a different, sibling variablethat shares the same root name (e.g.
tas→ expectedtasmin's string,sfcWind→ expectedsfcWindmax's string,hfls→ expected the ice-sheetvariant). This pattern indicates the branded-variable → registry resolution is
selecting the wrong registry entry, rather than ACCESS-MOPPy writing a wrong
long_name.This needs triage to decide ownership: either ACCESS-MOPPy is emitting an
incorrect branded-variable identifier that resolves ambiguously, or this is an
esgvoc / cc-plugin-wcrp registry-resolution bug.
Environment
compliance-checker --test wcrp_cmip6:1.0(cc-plugin-wcrp + esgvoc)Failing Checks (verbatim)
Analysis
got)expectedhflslong_name; expected belongs to the ice-sheet varianthurs; expected is an unrelated daily/crop-tile variantmrro; expected belongs to the ice-sheet variantrsds; expected is the over-snow variantrsus; expected is the open-ocean variantsfcWind; expected belongs tosfcWindmaxtas; expected belongs totasminwaplong_name; expected does not correspond towapIn every case the file's
long_namematches the standard CMIP6 string for thevariable, and the
expectedvalue corresponds to a different variable. Theresolution appears to collapse onto a sibling branded variable that shares the
same standard root.
Although some of those reported issues are not actually valid and are caused by the checker itself, the list is mainly for our reference.