Dealing with "total water" variants and water variants in general

[MarekWlasak]

Current definitions of moisture variables / overview of problem

The issue here is that there are numerous representations of variables involving mixing ratios.

The simplest are those that are that are mixing ratios with respect to dry air

m_v = water_vapor_mixing_ratio_wrt_dry_air
m_cl = cloud_liquid_water_mixing_ratio_wrt_dry_air
m_ci = cloud_ice_mixing_ratio_wrt_dry_air
m_r = rain_mixing_ratio_wrt_dry_air

There are two more:
m_s = cloud snow_mixing_ratio_wrt_dry_air
m_g = graupel_mixing_ratio_wrt_dry_air

And one composite (that we need to add asap)
m_cf = cloud_frozen_water_mixing_ratio_wrt_dry_air = m_s + m_ci

... At least these are the quantities that the Met Office will be using for the foreseeable future.
Note that hydrometeors are not unique in general and rain can be broken up into "drizzle" etc, but for now we are not worrying about this. Also some models have "hail" instead of ice.

In the Met Office note that the six variables that we will eventually be going with CASIM will be (m_v, m_ci, m_cl, m_r, m_s, m_g) and will be quite tightly specified. Note that in the global domain we need for now m_v, m_cl, m_cf, m_r.

Maybe we should make "_wrt_dry_air" default and not include it when present. That would reduce the length of the names at least by a little. This becomes particularly an issue later in description. From now will remove "_wrt_dry_air"

.i.e.
m_v = water_vapor_mixing_ratio
m_cl = cloud_liquid_water_mixing_ratio
m_ci = cloud_ice_mixing_ratio
m_r = rain_mixing_ratio
m_s = cloud snow_mixing_ratio
m_g = graupel_mixing_ratio
And one composite (that we need to add asap)
m_cf = cloud_frozen_water_mixing_ratio = m_s + m_ci

Total water with respect to dry air

Now total water of dry quantities depends on what is being accumulated.

For now it should be

m_t = m_v + m_cl + m_cf + m_r

But in the future it could be

m_t = m_v + m_cl + m_ci + m_s + m_r + m_g

I suggest that the former be called "total_of_water_vapor_cloud_water_rain_mixing_ratio" and the latter
"total_of_water_vapor_cloud_water_rain_graupel_mixing_ratio"

where we create a composite (for naming) to define "cloud_water":

cloud_water_mixing_ratio = m_cf + m_cl = m_s + m_ci + m_cl

Dealing with different denominators

Things get much more interesting / complicated when dealing the specific water quantities. Theoretically the numerator needs to take account of the total mass of the air parcel i.e the mass of all constituents. (Unfortunately approximations are made in practical definitions (including ESCOMP) which ignore these. Also, unfortunately observations use these variables and not the dry air counterparts.

However as a plus when calculating total water, the denominator used is the same for each component, so we could use that tag once.
If we make the "wrt" be defined by the dry air equivalent, we should always be on firm ground

So instead of "_wrt_dry_air" we can have

• "_wrt_water_vapor_mixing_ratio"
• "_wrt_total_of_water_vapor_cloud_water"

So specific humidity q_v = m_v / (1 + m_v) will be formally "water_vapor_mixing_ratio_wrt_water_vapor_mixing_ratio"

specific humidity variant q2_v = m_v /(1 + m_v +m_cl + m_cf + m_r) will be formulate as
"water_vapor_mixing_ratio_wrt_total_of_water_vapor_cloud_water_rain_mixing_ratio"

qT = total_of_water_vapor_cloud_water_mixing_ratio_wrt_total_of_water_vapor_cloud_water_rain_mixing_ratio"
= q2_v + q_cl + q_cf

where
q_cl = m_cl /(1 + m_v +m_cl + m_cf + m_r)
q_cf = m_cf /(1 + m_v +m_cl + m_cf + m_r)

And
q2T = total_of_water_vapor_cloud_water _rain_mixing_ratio_wrt_total_of_water_vapor_cloud_water_rain_mixing_ratio"
= q2_v + q_cl + q_cf + q_r

Note that given that the denominator will always include a mixing ratio it might make sense to remove the second mixing ratio from the names.

Differences between these names and existing names

The current names use:

1. "_wrt_moist_air" instead of "_wrt_water_vapor_mixing_ratio"
2. "_wrt_moist_air_and_condensed_water" instead of "_wrt_total_of_water_vapor_cloud_water"

The former are less precise, but less wordy.

[MarekWlasak]

@svahl991 @ss421 - do you agree?

[mkavulich]

@MarekWlasak I am still digesting your proposal, but I have a few early thoughts.

Maybe we should make "_wrt_dry_air" default and not include it when present. That would reduce the length of the names at least by a little. This becomes particularly an issue later in description. From now will remove "_wrt_dry_air"

Is the only desire here to reduce name lengths? I ask because mixing ratio discussions in the past have brought up that, while most weather-related applications assume "dry air" as the default denominator for a mixing ratio, many other fields such as atmospheric chemistry assume the total of all components except the numerator (i.e. r = n/total - n); while these definitions are equivalent for water vapor, they are not for other constituents. So it seems prudent to always specify the denominator, unless there is a more pressing reason why this convention might be needed.

As far as the rest of your proposal, I agree that something along these lines is needed, for cases where components with different hydrometeor classes and different ways of defining thee mixing ratios may go beyond a simple case. While theoretically the current rules suffice, it will result in impractically long and difficult to parse names. I'll need to put more thought into how an exact set of rules for dealing with these might be implemented.

m_cf = cloud_frozen_water_mixing_ratio_wrt_dry_air = m_s + m_ci

While I agree that hard definitions for shortcut terms like "liquid water" and "frozen water" could help this problem, my initial instinct is that "frozen water" should include all water ice variables, including graupel (and hail for models that treat it separately).

[climbfuji]

@MarekWlasak @mkavulich Apologies that this slipped through the cracks.

My concern is that wrt_dry_air isn't the default in NWP applications either. For instance, in CCPP physics used by the UFS (NOAA) and NEPTUNE (NRL), everything is based on dry air + water vapor (which is wrt_water_vapor_mixing_ratio if I am not mistaken).

In fact, until not too long ago we did have a "default" rule that said "if no wrt_... is provided then it is wrt dry air + water vapor". We removed that because it was confusing and different systems had different defaults.

Because of this I feel like we shouldn't make wrt_dry_air the default, but be explicit all the time.

I do like your suggestions

"_wrt_moist_air" instead of "_wrt_water_vapor_mixing_ratio"
"_wrt_moist_air_and_condensed_water" instead of "_wrt_total_of_water_vapor_cloud_water"

though.

[nusbaume]

Hi All,

Apologies for the slow response (was on vacation the past few weeks)! I can certainly see the need to have more precise standard names when one is using a combination of physical quantities within a given mixing ratio variable that don't neatly map onto a current standard name, and the suggestions for the "numerator" names described here seem reasonable to me. However, I do have a couple of concerns with the suggestions related to the "denominator" names (although if I am misunderstanding what is being suggested please let me know).

First, the terms wrt_moist_air and wrt_moist_air_and_condensed_water are rigorously defined, as listed out in the standard name rules (which I have copied here verbatim):

By default, mixing_ratio refers to mass mixing ratios. The long name should explicitly specify that it refers to the mass mixing ratio. Mass mixing ratios should contain information regarding with respect to what quantity they are defined, and options are wrt_dry_air, wrt_moist_air, or wrt_moist_air_and_condensed_water, where moist_air refers to dry air plus vapor and moist_air_and_condensed_water refers to dry air plus vapor and hydrometeors. Use of specific_humidity should be avoided as there is no consensus on whether it refers to mixing_ratio_of_water_vapor_wrt_moist_air or mixing_ratio_of_water_vapor_wrt_moist_air_and_condensed_water. total_water can be used to designate water in every form, i.e. water vapor plus condensed water.

As background, the initial discussion which came up with these names can be found here: #36

So I am not sure that the newly suggested names are actually more precise than the current versions, although as already mentioned these names do not account for mixing ratios which are not one of these three options (e.g. dry air + cloud water + cloud ice, but no rain), so I agree that we need to make a plan for this.

The other concern I have is that I generally interpret X_mixing_ratio_wrt_Y as "mass of X divided by mass of Y". So the current standard name water_vapor_mixing_ratio_wrt_moist_air would be interpreted as "mass of water vapor / (mass of dry air + mass of water vapor)". However, in this interpretation water_vapor_mixing_ratio_wrt_water_vapor_mixing_ratio would be equal to "mass of water vapor / (mass of water vapor / mass of dry air), which would be equal to just the mass of dry air (which would not be correct). So I am concerned that these name changes will potentially produce more confusion for users even if they are potentially shorter.

Of course, this is all just my personal opinion, and so am happy to discuss any of it further, especially if I am misunderstanding anything. Thanks!

[mkavulich]

@MarekWlasak Apologies for the long gaps in conversation, I have just finished with some time off for conferences and vacation so I hope to resolve your issue sooner rather than later.

Below I've tried to summarize the existing water/hydrometeor terms and potential combined aliases (some of which exist, some of which don't yet):

Base components

• Air/Dry air air
• Water vapor v
• Cloud liquid: cl AKA cloud droplets
• Cloud ice: ci
• Rain: r
• Snow: s
• Graupel: g
• Hail: h

Combined components

• moist_air air + v
• cloud_total_water: cl + ci = c
• liquid_water r + cl
• ice_water: s + g + h + ci
• hydrometeor: r + s + g + h + c
• precipitation: r + s + g + h
• ice_precipitation: s + g + h
• total_water: r + s + g + h + c + v

So the corresponding mixing ratios would be (adopting your notation from above):

• water_vapor_mixing_ratio_wrt_dry_air: m_v
• cloud_liquid_mixing_ratio_wrt_dry_air: m_cl
• cloud_ice_mixing_ratio_wrt_dry_air: m_ci
• rain_mixing_ratio_wrt_dry_air: m_r
• snow_mixing_ratio_wrt_dry_air: m_s
• graupel_mixing_ratio_wrt_dry_air: m_g
• hail_mixing_ratio_wrt_dry_air: m_h
• cloud_total_water_mixing_ratio_wrt_dry_air: m_cl + m_ci = m_c
• liquid_water_mixing_ratio_wrt_dry_air m_r + m_cl
• ice_water_mixing_ratio_wrt_dry_air: m_s + m_g + m_h + m_ci
• hydrometeor_mixing_ratio_wrt_dry_air: m_r + m_s + m_g + m_h + m_c
• precipitation_mixing_ratio_wrt_dry_air: m_r + m_s + m_g + m_h
• ice_precipitation_mixing_ratio_wrt_dry_air: m_s + m_g + m_h
• total_water_mixing_ratio_wrt_dry_air: m_r + m_s + m_g + m_h + m_c + m_v

The above all correspond to mixing ratios wrt dry air. I think part of the confusion above with naming comes from using specific humidity definitions based on mixing ratios wrt dry air, rather than the mass-based definitions that @nusbaume alluded to above. With these more fundamental definitions, as well as the terms defined above, the standard names for your above-requested quantities would be:

• m_s + m_ci = m_cf : snow_and_cloud_ice_mixing_ratio_wrt_dry_air
• q_v = m_v / (1 + m_v) = mass_vapor/mass_moist_air: water_vapor_mixing_ratio_wrt_moist_air
• q2_v = m_v /(1 + m_v +m_cl + m_cf + m_r) = mass_vapor/(mass_moist_air + mass_hydrometeors): water_vapor_mixing_ratio_wrt_moist_air_and_hydrometeors
• q_cl = m_cl /(1 + m_v +m_cl + m_cf + m_r) = mass_cloud_liquid/(mass_moist_air + mass_hydrometeors): cloud_liquid_mixing_ratio_wrt_moist_air_and_hydrometeors
• q_cf = m_cf /(1 + m_v +m_cl + m_cf + m_r) = (mass_snow + mass_cloud_ice)/(mass_moist_air + mass_hydrometeors): snow_and_cloud_ice_mixing_ratio_wrt_moist_air_and_hydrometeors
• qT = q2_v + q_cl + q_cf = (mass_vapor + mass_cloud + mass_snow)/(mass_moist_air + mass_hydrometeors): water_vapor_and_snow_and_cloud_total_water_mixing_ratio_wrt_moist_air_and_hydrometeors
• q2T = q2_v + q_cl + q_cf + q_r = (mass_vapor + mass_cloud + mass_rain + mass_snow)/(mass_moist_air + mass_hydrometeors): water_vapor_and_rain_and_snow_and_cloud_total_water_mixing_ratio_wrt_moist_air_and_hydrometeors

I'll admit that a potentially problematic assumption I've made above is that, for a scheme such as CASIM where hail is not included, we can still allow, for example, total_water to mean r + s + g + c + v, and assume that the mass of hail is zero. While this obviously works within the scheme and a model expecting that behavior from that scheme, it is a question as to whether this might cause problematic interactions between schemes/models that have different numbers of hydrometeor classes. If that concern is valid, we may have to define additional categories, e.g. hydrometeors_excluding_hail, hydrometeors_excluding_hail_and_graupel, etc.

Now, these later names are admittedly long, but they are still less than 100 characters, and shorter than dozens of longer names already in use. However, if it is an absolutely insurmountable problem (especially if additional exclusion qualifiers mentioned above are needed), perhaps it would make sense to define a specialized, scheme-specific term for these more complicated definitions? For example, qT = casim_total_water_mixing_ratio and q2T = casim_total_water_mixing_ratio_2, with the long_name providing the detailed definition?

[mkavulich]

@MarekWlasak just checking in to see if you've had a chance to review my comments