Should we be using specific humidity or water vapor mixing ratio?

[PeterCaldwell]

@AaronDonahue recently noticed that E3SM computes saturation mixing ratio as qsat=eps*e_s/(P-(1-eps)*e_s) where eps=0.622, e_s is saturation vapor pressure, and P is the total pressure. In SCREAM, we've been using qsat=eps*e_s/(P-e_s), which we inherited from WRF-P3 and (in the case of SHOC), from SAM.

The (1-eps) difference between these formulations is due to whether we're computing the mass of water per kg of total air mass or per kg of dry air. Normalizing by total air gives us the "specific humidity" and normalizing by dry air is the formal definition for "mixing ratio". E3SM uses specific humidity and WRF and SAM apparently use mixing ratio.

The practical difference between these definitions is tiny because P>>e_s, but we do need to do the right thing. So - what is the right thing? I have the vague sense that the choice of dry or moist air mass is related to whether the dycore is framed in terms of dry or moist pressure, which leads us to need specific humidity. Can someone confirm or deny?

[mt5555]

adding some background information: The dycore always uses total air mass for the mixing ratio (wet mixing ratio). in E3SM, tracers can be set to either dry or wet in the physics, and there is code to convert all the dry tracers before and after the physics. In E3SM, I believe most tracers are wet, so there is no conversion - but there may be a few that get converted to dry mixing ratios.

SCREAM could either adopt the E3SM conventions for physics, or SCREAM could specifically set the tracers to wet or dry, which ever it prefers.

[mt5555]

This information is in the atm.log file. unless the SCREAM-HR compset changes this: all the water variables are wet (total mass mixing ratio), while all other tracers are sent to the physics as dry mixing ratios:

Advected constituent list: 1 Q Specific humidity wet 2 CLDLIQ Grid box averaged cloud liquid amount wet 3 CLDICE Grid box averaged cloud ice amount wet 4 NUMLIQ Grid box averaged cloud liquid number wet 5 NUMICE Grid box averaged cloud ice number wet 6 RAINQM Grid box averaged rain amount wet 7 SNOWQM Grid box averaged snow amount wet 8 NUMRAI Grid box averaged rain number wet 9 NUMSNO Grid box averaged snow number wet 10 O3 O3 dry 11 H2O2 H2O2 dry 12 H2SO4 H2SO4 dry 13 SO2 SO2 dry 14 DMS DMS dry 15 SOAG SOAG dry 16 so4_a1 so4_a1 dry 17 pom_a1 pom_a1 dry 18 soa_a1 soa_a1 dry 19 bc_a1 bc_a1 dry 20 dst_a1 dst_a1 dry 21 ncl_a1 ncl_a1 dry 22 mom_a1 mom_a1 dry 23 num_a1 num_a1 dry 24 so4_a2 so4_a2 dry 25 soa_a2 soa_a2 dry 26 ncl_a2 ncl_a2 dry 27 mom_a2 mom_a2 dry 28 num_a2 num_a2 dry 29 dst_a3 dst_a3 dry 30 ncl_a3 ncl_a3 dry 31 so4_a3 so4_a3 dry 32 bc_a3 bc_a3 dry 33 pom_a3 pom_a3 dry 34 soa_a3 soa_a3 dry 35 mom_a3 mom_a3 dry 36 num_a3 num_a3 dry 37 pom_a4 pom_a4 dry 38 bc_a4 bc_a4 dry 39 mom_a4 mom_a4 dry 40 num_a4 num_a4 dry chem_surfvals_init: ghg surface values are fixed as follows

[mt5555]

In the new SCREAM driver, maybe we could simplify things and communicate tracer mass between dycore and physics? tracer mass is unambiguous, and then any component that wants a mixing ratio is forced to compute the exact mixing ratio that it is interested in.

[bartgol]

Ah, I just ran into this issue, and today I was just asking on slack about the apparently inconsistent formulas used to convert T<->T_virt in scream and homme.

@PeterCaldwell , since we agreed our tracers will always be wet, can we say this issue is settled, i.e., we should do what Homme does for now (specific humidity wins)?

[PeterCaldwell]

@bartgol - I think we're clear on what we should do, but I don't think we've made the changes to actually do the thing we think we should. So I'm hesitant to close this issue.

[bartgol]

Ok. I thought the issue was more like a "survey" of opinions rather than an action item.

So this issue should now be considered as something like "ensure all processes treat tracers from the FM as wet". Perhaps we can close this and open one that is more of an action item, so that who has free cycles can take it (along with creting wet<->dry conversion min functions).

[PeterCaldwell]

Yeah, sounds good. I'll close this and open a new issue.