Exner function definition differs from the standard one

[glwagner]

The LiquidIcePotentialTemperatureState currently defines the Exner function via

Breeze.jl/src/Thermodynamics/dynamic_states.jl

Lines 31 to 38 in d2abe9d

	@inline function exner_function(𝒰::LiquidIcePotentialTemperatureState, constants::ThermodynamicConstants)
	q = 𝒰.moisture_mass_fractions
	Rᵐ = mixture_gas_constant(q, constants)
	cᵖᵐ = mixture_heat_capacity(q, constants)
	pᵣ = 𝒰.reference_pressure
	p₀ = 𝒰.base_pressure
	return (pᵣ / p₀)^(Rᵐ / cᵖᵐ)
	end

or in other words

$$ \Pi = \left ( \frac{p_r}{p_0} \right )^{R^m / c^{pm}} $$

where $p_0$ is the "base pressure" of the formulation; ie the reference pressure at $z=0$.

This would seem normal based on an ordinary derivation of potential temperature, which involves integrating the first law; in that process we define $\theta(z=0) = \theta_0$ and $p(z=0) = p_0$. (Dry potential temperature is defined as $\theta = T / \Pi$.)

However it is not actually required to define "p at z=0" in the same way for the reference pressure used in the anelastic approximation...

In particular the standard definition of potential temperature uses $10^5$ Pa instead, ie defining the Exner function as

$$ \Pi = \left ( \frac{p_r}{10^5} \right )^{R^m / c^{pm}} $$

regardless of whether there is "another reference pressure" for $p(z=0)$. Although some even use the exponent $R^d / c^{pd}$ rather than the moist part (Pauluis 2008 argued that omitting moisture violates the first law).

For example: https://glossary.ametsoc.org/wiki/Potential_temperature

It's apparently so standard, so so standard that Siebesma et al 2003 don't need to mention it at all. Some people are actually born knowing it, it is said.

This was pointed out by @trontrytel in #21 (comment).

We may really need to use this definition of the Exner function if we want our $\theta$ to be the standard potential temperature (well, the liquid-ice potential temperature anyways, which is not really standard either. Many people assume that when you say "potential temperature" you mean dry potential temperature).

In turn this requires either 1) hard-coding 1e5 or 2) introducing a new parameter, like potential_temperature_reference_pressure or something. Probably we want to put the parameter inside ReferenceState, and it also needs to be added to LiquidIcePotentialTemperatureState. Which could sadly have some kind of cost in terms of GPU parameter space, but not sure if it would be a real issue or not.

[glwagner]

There's some relevant discussion on #228 as well. We found that not accounting for this was corrupting bomex results, ie the difference between

and

[bischtob]

🤯

[kaiyuan-cheng]

Interesting. For dycore, the specific definition of potential temperature shouldn't make a difference. For example, FV3 uses p_0 = 1 Pa so as to save some computational cost. For post-processing, however, p_0 = 1000 hPa is definitely the appropriate choice.

[glwagner]

Interesting. For dycore, the specific definition of potential temperature shouldn't make a difference. For example, FV3 uses p_0 = 1 hPa so as to save some computational cost. For post-processing, however, p_0 = 1000 hPa is definitely the appropriate choice.

Aha that is pretty epic.

The distance between "source code" and "post processing" is a lot thinner or even not really existent in Breeze. For example, users can access internal variables at any time. I think it would be dangerous to use different conventions in the source code versus what should be used for post-processing. So I think this is a vote in favor of adding a new parameter!

[bischtob]

The distance between "source code" and "post processing" is a lot thinner or even not really existent in Breeze. For example, users can access internal variables at any time. I think it would be dangerous to use different conventions in the source code versus what should be used for post-processing. So I think this is a vote in favor of adding a new parameter!

Very true!