Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design choices towards stochastic parameterizations #199

Open
milankl opened this issue Nov 30, 2022 · 1 comment
Open

Design choices towards stochastic parameterizations #199

milankl opened this issue Nov 30, 2022 · 1 comment
Labels
parameterizations 🌧️ Parameterizations of unresolved physical processes structure 🏠 Internal structure of the code

Comments

@milankl
Copy link
Member

milankl commented Nov 30, 2022

Several classes of stochastic parameterizations with multiplicative noise that are currently in use/proposed

  • SPPT: Stochastically perturbed parameterization tendencies
  • SPP: Stochastically perturbed parameters
  • SPPI: Stochastically perturbed parameterization inputs SPPI (I believe I'm sofar the only one who seriously suggested this other than Tim Palmer who mentioned that idea in a paper 20 years ago)

Let $V$ be any prognostic variable, and $r$ a random number following some distribution (sometimes people write 1+r with r symmetric around 0, but let's keep it general here), and some set of parameters $p_i$

  1. SPPT:
    $\partial_t V = Dynamics(V) + r*Physics(V, p_i)$

$r$ is usually the same for all $V$, but space/time dependent with some autocorrelation time/length scale. Ideally, one would want r to be independent of height (to only perturb fluxes), but for stability reasons that used to be tricky, hence ECMWF did some tapering in the planetary boundary layer / stratosphere.

  1. SPP: $\partial_t V = Dynamics(V) + Physics(V, r*p_i)$

Here, every parameter $p_i$ gets its own $r$, but the pattern generation is similar to SPPT. Not sure about vertical depedency.

  1. SPPI: $\partial_t V = Dynamics(V) + Physics(V_r, p_i)$

Here, the physical parameterizations are evaluated from a perturbed state $V_r$ that's obtained similar to SPPT: $V_r = V(t-\Delta t) + \Delta t* (Dynamics(V) + r*Physics(V, p_i))$. This has the advantage that any flux inconsistencies are immediately resolved and the SPPT idea to perturb those physics tendencies the strongest that are also the largest is retained. How exactly to do that, we'll have to see, but I believe that can be done without any additional computational burden within parameterization_tendencies! (tendencies from previous time steps are still available and one can do a simple, cheap time stepping to obtain a perturbed state)

What that means for SpeedyWeather.jl:

Fortran-SPEEDY computes things in the following order:

  1. $P = Physics(V,p_i)$ (grid-point space)
  2. $P$ += $Dynamics(V)$ (+= in grid-point space)
  3. convert $P$ to $P_s$ in spectral space ($P$ is not overwritten)
  4. time stepping in spectral space with $P_s$

Sofar I didn't have the intention to change that, but maybe we have to:

  • For SPPT not many changes would be needed other than holding $r$ in spectral space as a field, evolve it as AR1 and on every time step transform to grid-point space to be used in $Physics(V,p_i)$.
  • For SPP we want to think about a general structure how to hold the parameters (Overhaul approach to physical constants and model parameters #86) such that when calling parameterization_tendencies! we can also call a perturb_parameters! function that does that either in-place or by creating a copy. In this case, we may want to be able to give parameters an uncertainty (e.g. run_speedy(param1=1.23±0.3) via Measurements.jl)
  • For SPPI we also need $r$ as for SPPT, but then would also need to think about mimicking SPPT-like time stepping in grid-point space (in spectral space the backtransforms would be too expensive to make it attractive I think).

@white-alistair @dmey @justinfocus12

@milankl milankl added structure 🏠 Internal structure of the code parameterizations 🌧️ Parameterizations of unresolved physical processes labels Nov 30, 2022
@milankl milankl added this to the v0.6 milestone Nov 30, 2022
@milankl
Copy link
Member Author

milankl commented Jun 9, 2023

@emilemathieu

@milankl milankl modified the milestones: v0.6, v0.7 Aug 30, 2023
@milankl milankl removed this from the v0.7 milestone Mar 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parameterizations 🌧️ Parameterizations of unresolved physical processes structure 🏠 Internal structure of the code
Projects
None yet
Development

No branches or pull requests

1 participant