Dry air vs. moist air and tracer units

[pbosler]

DECISION: we are using dry air mixing ratios as prognostics in mam4xx, just like mam4 and many other aerosol packages. Conversions will be done between dry and moist air quantities in EAMxx.

Summary

The dynamics of Eamxx are defined with respect to moist air so that, for example, the water vapor tracer qv is given as water content per unit of total air, e.g., density water vapor / density total air. Many of our aerosol parameterizations are defined with respect to dry air, so we have to be alert to this inconsistency both for bug detection in the existing code and to make sure we don't introduce new bugs in Mam4xx.

Fortunately, atmospheric scientists give us two terms that distinguish between definitions for water vapor:

1. Water vapor mixing ratio, usually given the symbol w, is defined with respect to dry air as kg h2o vapor / kg dry air or density h2o vapor / density dry air.
2. Specific humidity, usually given the symbol q, is defined with respect to moist air as kg h2o vapor / kg moist air (or densities).

For other tracers, such as aerosols mass and number concentrations/mixing ratios etc., we'll need to be careful to know whether or not they are defined with respect to dry air or moist air.

The file conversions.hpp contains functions that convert to and from each (moist or dry) representation for water vapor; for other tracers we'll need to write analogous methods.

This web page matches the definitions from standard meteorology texts and shows how to convert between moist and dry water vapor content definitions.

To-do:

• Write conversion function for mass mixing ratio defined with respect to moist air to the same mass ratio with respect to dry air
• Write the inverse conversion
• Write unit tests

[singhbalwinder]

I added these functions in SCREAM recently (wet->dry and dry->wet) for all tracers that SCREAM carries. We need to find a way to make them available to the codes outside of SCREAM. This is the same situation as qsat. It is defined within SCREAM but we need it for aerosol processes as well.

[jeff-cohere]

As I've discussed with a few of you, it seems like we could actually get dry-air quantities from SCREAM for our aerosol calculations and then have SCREAM's aerosol atmosphere process handle conversions to/from the aerosol package. In fact, SCREAM already has some fields for dry-air quantities, even though it deals primarily with their moist-air equivalents.

The nice thing about this approach is that we don't have to think about dry air vs. moist air in our aerosol parameterizations. This brings us more in line with the rest of the aerosol physics community (if I'm not mistaken), and confines dry/moist conversion issues to a single location: the aerosol atmosphere process in SCREAM.

If we adopt this approach, I would like to change the Atmosphere class in Haero so its quantities are all w.r.t. dry air.

What say yous, @pbosler @singhbalwinder @pressel ?

[pbosler]

I like the idea of picking a convention and sticking to it. I have no opinion on whether or not dry is better than moist for such a convention. Moist air was chosen for the dynamical core for reasons cited in Taylor et al., 2020, and sticking with that convention would keep us more in line with Eamxx. But if most parameterizations use dry air, and Eamxx has to convert for other parameterizations such as P3 anyway, dry air is a good option, too.

Generally, physics parameterizations are harder to wrangle than dynamics, so whichever option makes physics simpler is probably best.

[singhbalwinder]

I agree. All the aerosols and gasses in MAM4 are assumed to be dry, so I think it is best to keep it that way. We can do the conversion (wet<->dry) using the scream utility functions in the MAMxx interface routine.

[jeff-cohere]

I'm asking around about other aerosol packages. I'll report what I find.

[jeff-cohere]

From Nicole Riemer (author of PartMC at UIUC):

"We are in the “dry air” camp, because otherwise one needs to adjust the mixing ratio every time one evaporates or condenses some water or when the moisture gets updated otherwise by transport, which would be confusing. It’s similar to reporting aerosol size distributions w.r.t. “dry diameter” because the actual diameter always adjusts to the ambient relative humidity and changes accordingly.

It’s a good question what “most” aerosol packages use — I would assume it’s dry air, but honestly am not sure."

[jeff-cohere]

From Manish Shrivastava (at PNNL, but familiar with WRF):

"I think WRF also uses ug/kg dry air"

I have questions out to people from CMAQ and CARMA as well.

[jeff-cohere]

From Ben Murphy (EPA's CMAQ):

"We are pretty much always transporting in "dry" mass mixing ratios to my knowledge. At least, that's how I interpret concentrations when converting to total mass.

Incidentally, we are also usually "dry" in the sense that we store size distribution parameters consistent with no water on the particles, although we do store the mass of particulate water.

...that at least partly is motivated by the fact that aerosols are typically dried when analyzed."

[singhbalwinder]

Thanks for collecting these! Looks like everyone agrees on using the dry mmrs for the aerosols, which is the same as our plan for MAM4.

[jeff-cohere]

I looked through the CARMA source, and it looks like they store number concentrations instead of mixing ratios, which are indifferent to this wet/dry air question. Nevertheless, I think we'll get an answer from Chuck Bardeen (author) sometime soon.

Given our sampling so far, I think it's fair to say that dry air seems to be the favored approach among aerosol models. And given that Haero doesn't actually place constraints on the aerosol prognostic variables (only the atmospheric state, as represented in its Atmosphere class), the decision at stake here is actually more peculiar to MAM4xx than a question of general aerosol interfaces.

I propose two things:

1. In Haero, we stipulate that the pressure within the Atmosphere type is total atmospheric pressure, for clarity. I am assuming here that when people say "pressure" or "atmospheric pressure", they mean the total pressure and not the partial pressure of dry air. If I'm wrong about this, I would appreciate someone letting me know!
2. In MAM4xx, we use (dry) mixing ratios, just like MAM4. We convert the specific humidities (wet mixing ratios) to their dry counterparts in the AtmosphereProcess(es) that connect SCREAM's Atmospheric Driver (AD) to MAM4xx.

How does this sound?

[pbosler]

2. In MAM4xx, we use (dry) mixing ratios, just like MAM4. We convert the specific humidities (wet mixing ratios) to their dry counterparts in the AtmosphereProcess(es) that connect SCREAM's Atmospheric Driver (AD) to MAM4xx.

I think we do this already --- at least for water vapor, since vapor_mixing_ratio is a member of haero::Atmosphere (not specific humidity). See, for example, init_atm_const_tv_lapse_rate in mam4xx/src/tests/atmosphere_utils.cpp. However, this example is only used for unit tests. Ultimately, to do this for the library, we'll need @singhbalwinder's functions discussed above,

I added these functions in SCREAM recently (wet->dry and dry->wet) for all tracers that SCREAM carries. We need to find a way to make them available to the codes outside of SCREAM.

to construct a dry-air AeroConfig from EamXX's moist air tracers.

For the time being, we should consider renaming the variables in Prognostics. In the atmospheric texts, the variable q is used for specific humidity, while w is used for vapor mixing ratio, so using q for aerosol mixing ratio in Prognostics is doubly ambiguous: both aerosols vs. water, and mixing ratio vs. specific concentration are not clear. Using w is also problematic, since it's also used for vertical velocity.

To be more descriptive, e.g., instead of q_aero_i, perhaps aerosol_mass_mixing_ratio_interstitial, aero_mass_mix_ratio_clear, with similar renames for clouds and gases?

[jeff-cohere]

I think being descriptive is good, but I think as long as we document what a variable is we can probably get by with shorter names. I think it's hard to argue that aero means anything but "aerosol" here, and mass_mixing_ratio could be mmr, which seems to be used in the community. Regarding "interstitial" and "cloudborne"... well, those are very long words, and not as easily collapsed: int sounds like "integer", though cld is less ambiguous. In my experience, very very very long variable names take up a lot of horizontal space, which can lead to strange developer behavior. :-)

This is just my $0.02, of course. What about other opinions?

[jeff-cohere]

Let's move the variable name discussion to #74.