ali-ramadhan
commented
4 years ago Just documenting some of the things we talked about earlier today.
- I think we agreed to use height coordinates. I assume we want to start with flat-bottom Cartesian coordinates, i.e. ζ(x, y, z) = z following K07?
Yes, and actually an immersed boundary method could be a simpler way of implementing boundary conditions as the terrain-following height coordinates ζ(x, y, z) are quite complicated to implement.
- I probably just misunderstood things but the advection term in K07's Eq. (4)-(9) seems to suggest that advection terms are made up of three terms, while the CM1 manual suggests six terms in their Eq. (6)-(7).
K07 writes the equations down in convective form while the CM1 manual uses the conservation form (or flux form) which we want as conservation is a nice property to have for long integration times.
Followup question: What do you gain by not using the conservation form? Is it just fewer operations and more efficient when you don't care about conserving stuff, i.e. for a 24-hour simulation of a thunderstorm?
- Seems that you can't run a model with just U, V, W (and no buoyancy) as a temperature-like variable such as entropy
sor modified virtual temperatureθₘis required to diagnose the pressure and evolve U, V, W?
Generally yes.
- What is the minimal set of prognostic variables you can evolve? If a temperature-like variable is required then it seems to be U, V, W, S, and ρ?
Yes (for non-hydrostatic compressible atmosphere).
- Does it make sense to design the code such that the prognostic temperature-like variable can be changed in the future? We've chosen entropy
sbut maybe there's a reason to choose modified virtual temperature or enthalpy?
Yes and actually this could be a really neat feature that other models don't have. Even cooler would be if the user can easily define their own temperature-like prognostic variable.
We should try to write the code such that adding a new temperature-like prognostic variable just involves defining a new buoyancy_perturbation function, etc. like Oceananigans does for new equations of state.
- Setting initial conditions seems to be non-trivial because users usually want to specify velocities u, v, w and temperature T. But these are not the prognostic variables. Am I right in assuming that velocities get converted into momenta U, V, W and the temperature gets converted to entropy s, after which the initial density is computed?
Apparently atmospheric models do something weird to produce a hydrostatic base state as otherwise the initial adjustment produces large amplitude acoustic waves that usually blow up your simulation. This happens because the prognostic variables are perturbations around a hydrostatic base state.
It's slightly discomforting (for me at least) to know that the model won't actually respect the initial conditions you've set.
Not sure how much work it is but I wonder if we could use a base_state = nothing option where no base state is assumed and maybe then you can define crazy initial conditions? Is there any use case for this?
- A "time-invariant hydrostatically balanced dry reference state" is used to define perturbation variables as deviations from this reference state. Is there only one way to define this base state? The base state actually enters in the acoustic time steps so presumably changing the base state will change the dynamics?
Apparently the base state can be computed from the initial conditions so that the initial condition is pretty close to hydrostatic balance (otherwise it blows up) and could be (slowly) time-varying. In general it seems to depend on the simulation.
- While entropy
sand the mixing ratiosqv,ql,qi, etc. are all tracers, it seems they should be separated into difference structs as the temperature-like prognostic variable effects how both pressure and buoyancy are computed, while your choice of moist species affects your cloud microphysics and you can run without any moist species. Seems to make sense that passive tracers (e.g. ) should be further separated into a different struct.
Consensus seemed to be that entropy and mixing ratios shouldn't receive special status and could indeed be lumped together into a tracers struct like Oceananigans does it.
- Am I right in assuming that a cloud microphysics scheme just picks a number of moist species to evolve (expressed as mixing ratios) and adds terms to the right-hand-side of their evolution equations to specify how they interact?
Yes. Although fancy two-moment schemes, for example, can also evolve probability distributions for number of droplets or droplet size.
- How would user-defined forcing terms work?
Most user-defined forcing functions will be relatively cheap to evaluate (compared to radiation and LES models) and so can be evaluated at every RK3 step. Makes most sense to allow for these forcing functions first. Forcing functions for "slow" physics and acoustic waves can come later as they have fewer use cases.
Took another attempt at reading through the algorithm notes and Klemp et al. (2007) [K07] but had some questions as I'm thinking about how we can code this all up.
Apologies for the spam of questions! Not expecting a reply on GitHub!
I think we agreed to use height coordinates. I assume we want to start with flat-bottom Cartesian coordinates, i.e. ζ(x, y, z) = z following K07?
I probably just misunderstood things but the advection term in K07's Eq. (4)-(9) seems to suggest that advection terms are made up of three terms, while the CM1 manual suggests six terms in their Eq. (6)-(7).
Seems that you can't run a model with just U, V, W (and no buoyancy) as a temperature-like variable such as entropy
sor modified virtual temperatureθₘis required to diagnose the pressure and evolve U, V, W?What is the minimal set of prognostic variables you can evolve? If a temperature-like variable is required then it seems to be U, V, W, S, and ρ?
Does it make sense to design the code such that the prognostic temperature-like variable can be changed in the future? We've chosen entropy
sbut maybe there's a reason to choose modified virtual temperature or enthalpy?Setting initial conditions seems to be non-trivial because users usually want to specify velocities u, v, w and temperature T. But these are not the prognostic variables. Am I right in assuming that velocities get converted into momenta U, V, W and the temperature gets converted to entropy s, after which the initial density is computed?
A "time-invariant hydrostatically balanced dry reference state" is used to define perturbation variables as deviations from this reference state. Is there only one way to define this base state? The base state actually enters in the acoustic time steps so presumably changing the base state will change the dynamics?
Is the reference surface pressure p₀ user-defined? Is it a constant or is it p₀ = p₀(x, y)? It seems like changing p₀ would change the dynamics. Not sure if a 2D field makes sense as it implies topography which is taken care of by ζ(x, y, z). Any changes in surface pressure would be accounted for in p′.
While entropy
sand the mixing ratiosqv,ql,qi, etc. are all tracers, it seems they should be separated into difference structs as the temperature-like prognostic variable effects how both pressure and buoyancy are computed, while your choice of moist species affects your cloud microphysics and you can run without any moist species. Seems to make sense that passive tracers (e.g. ) should be further separated into a different struct.Am I right in assuming that a cloud microphysics scheme just picks a number of moist species to evolve (expressed as mixing ratios) and adds terms to the right-hand-side of their evolution equations to specify how they interact?
Do moist species contribute to buoyancy solely through the moist density
ρ_m?If we wanted to evolve the acoustic modes explicitly, would this make sense as the smallest modification on the vertically implicit method? Not sure if it's more stable/accurate if we calculate W″(τ+Δτ) first, or if we calculate S″(τ+Δτ) and ρd″(τ+Δτ) first. Maybe they're both bad.
How would user-defined forcing terms work? I see the potential for three different kinds of forcing terms:
Fterms in Eq. (4)-(8) of K07. These apparently "contain the Coriolis and diffusion terms as well as diabatic effects and any parameterized physics that arise in a full atmospheric prediction model". Seems like an LES diffusivity would be calculated here?Rterms in Eq. (13)-(16) of K07.I'm confused by Figure 3.1 of the WRF4 manual between steps (1) and (9). Step (1) is described as computing "physics tendencies including mixing" during the first RK step while step (9) is "compute non-RK3 physics (currently microphysics)". So it seems that microphysics enjoys a special status as it's computed separately at the end of every large time-step. Seems to me they can be combined?
Do we envision supporting topography one day? Would that involve switching to the terrain following coordinates ζ(x, y, z)? We've been thinking of an immersed boundary method for Oceananigans where the boundary is accounted for by adding forcing terms to the momentum equations so no refactoring is required and the pressure solver doesn't have to change.