Update several units in CCPP metadata following CCPP framework update

[climbfuji]

Description

With the metadata parser update in NCAR/ccpp-framework#415, a stricter checking of units will be enforced. This includes the replacement of "convenience units" such as log(Pa) with 1. The following changes are made in ccpp-physics and fv3atm:

• Replace units 'various' with 'mixed' as agreed upon on the ccpp-framework developer committee
• Update several invalid convenience units of non-physical quantities with 1
• Correct the units of the relative humidity variables of the maximum hourly diagnostics from % to frac (because they are not percentages, but range from zero to one)
• Update submodule pointers for ccpp-framework and ccpp-physics

Issue(s) addressed

n/a

Testing

See ufs-community/ufs-weather-model#907

Dependencies

• waiting on Update main from feature/capgen 11/09/2021 (stricter checking of units in CCPP metadata), update CODEOWNERS - requires Python 3.6 or newer NCAR/ccpp-framework#415
• waiting on Update several units in CCPP metadata, contains "Expanded format fields for percentages ..." (#777), update CODEOWNERS NCAR/ccpp-physics#775

[junwang-noaa]

May I ask what is the meaning of "units 1" and "units mixed"? Maybe you can see the units in NCEP grib2 product table as a reference? https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-2-0-1.shtml

[climbfuji]

Relative humidity in the code is expressed between 0 and 1, i.e. as a fraction. If it was a real percentage, it would range from 0 to 100. See the actual code in ccpp-physics.

Note also we do have percent as a valid unit for such quantities. The % symbol is not acceptable as a unit in the CCPP, it causes all sorts of problem with parsing code (also because members of derived data types have a percent in the name, e.g. foo%bar). We could use fraction instead of 1 for relative humidity, but if so we need to go back to the CCPP framework developers and have them confirm.

Any variable that is a number without a physical unit can have unit 1.

mixed is simply replacing various and is used in cases where a variable contains multiple units. For example, the grab-bag tracer array qgrs contains mass mixing ratios (kg kg-1), number concentrations (kg-1), cloud amount (fraction or 1, can't remember) etc. When the individual members of the qgrs array are passed, then the correct units can be used. But when the entire array is passed, we need to use mixed (was various until now).

Lastly, note that CCPP units do not follow the standard in https://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_doc/grib2_table4-2-0-1.shtml. If they do match, that is great, and we should strive for consistency where possible. But CCPP units follow CF conventions and udunits, with the extensions defined in https://github.com/ESCOMP/CCPPStandardNames/blob/main/StandardNamesRules.rst (as approved by the CCPP framework developer team).

[climbfuji]

Comparing the grib2 doc with what we have I see a nearly 100% match. The only difference is that we use percent instead of % for real percentages. Some units may differ from scheme to scheme (e.g. Thompson MP defines cloud effective radii in micron), but this is why we have automatic unit conversions - this way the host models can keep their units and still use the physics as-is.

[junwang-noaa]

I think all the NCPE productions are using these tables (most fields are from WMO except some local fields). For easy communication, can we use "fraction" or "percent" instead of "1" in the host model then?

…

On Wed, Nov 10, 2021 at 11:37 AM Dom Heinzeller ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In ccpp/data/GFS_typedefs.meta <#422 (comment)>: > dimensions = (horizontal_loop_extent) type = real kind = kind_phys [rh02min] standard_name = minimum_relative_humidity_at_2m_over_maximum_hourly_time_interval long_name = minumum relative humidity at 2m over maximum hourly time interval - units = % + units = 1 Comparing the grib2 doc with what we have I see a nearly 100% match. The only difference is that we use percent instead of % for real percentages. Some units may differ from scheme to scheme (e.g. Thompson MP defines cloud effective radii in micron), but this is why we have automatic unit conversions - this way the host models can keep their units and still use the physics as-is. — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub <#422 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI7D6TOLPEN35Y47QM4HEGLULKNUDANCNFSM5HX7NV6Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[climbfuji]

We cannot use percent if the quantities range between 0 and 1. Percentages by definition range from 0 to 100. Using percent for "relative humidity" when it is bounded by zero and one is incorrect. We can use fraction, though.

…

On Nov 10, 2021, at 10:19 AM, Jun Wang ***@***.***> wrote: I think all the NCPE productions are using these tables (most fields are from WMO except some local fields). For easy communication, can we use "fraction" or "percent" instead of "1" in the host model then? On Wed, Nov 10, 2021 at 11:37 AM Dom Heinzeller ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In ccpp/data/GFS_typedefs.meta > <#422 (comment)>: > > > dimensions = (horizontal_loop_extent) > type = real > kind = kind_phys > [rh02min] > standard_name = minimum_relative_humidity_at_2m_over_maximum_hourly_time_interval > long_name = minumum relative humidity at 2m over maximum hourly time interval > - units = % > + units = 1 > > Comparing the grib2 doc with what we have I see a nearly 100% match. The > only difference is that we use percent instead of % for real percentages. > Some units may differ from scheme to scheme (e.g. Thompson MP defines cloud > effective radii in micron), but this is why we have automatic unit > conversions - this way the host models can keep their units and still use > the physics as-is. > > — > You are receiving this because your review was requested. > Reply to this email directly, view it on GitHub > <#422 (comment)>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AI7D6TOLPEN35Y47QM4HEGLULKNUDANCNFSM5HX7NV6Q> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. > > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#422 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB5C2RL5B527TZEW6PVIX7DULKSRPANCNFSM5HX7NV6Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[climbfuji]

We cannot use percent if the quantities range between 0 and 1. Percentages by definition range from 0 to 100. Using percent for "relative humidity" when it is bounded by zero and one is incorrect. We can use fraction, though.
…

If you are interested, here is the discussion about relative humidity in the ESCOMP CCPPStandardNames dictionary: ESCOMP/ESMStandardNames#26

[climbfuji]

Here is the corresponding code in maximum_hourly_diagnostics.F90 that shows that the variables in question in this PR are indeed bounded by 0 (or RHmin = 1.0E-6), and 1, not by 0 and 100:

...
          rh02=q2m(i)/QCQ
          IF (rh02 > 1.0) THEN
             rh02 = 1.0
          ENDIF
          IF (rh02 < RHmin) THEN !use smaller RH limit for stratosphere
             rh02 = RHmin
          ENDIF
          rh02max(i) = max(rh02max(i),rh02)
          rh02min(i) = min(rh02min(i),rh02)

[climbfuji]

@junwang-noaa Please see this comment regarding fraction vs 1 - ESCOMP/ESMStandardNames#26 (comment)

[climbfuji]

I checked the hashes for ccpp-framework and ccpp-physics, they look correct to me. Ready to merge.