ClimaAtmos.jl is a library for building atmospheric circulation models that is designed from the outset to leverage data assimilation and machine learning tools. We welcome contributions!
We want to refactor EDMF code in ClimaAtmos.jl. Currently EDMF is filtering based on the updraft area fraction, updraft vertical velocity and to ensure tracer positivity. We want to replace some of those filters with regularisations, change the way we handle boundary conditions, delete the unnecessary filters and move what we can to the tendency evaluation. We also want to use ClimaCore/ClimaAtmos advection operators, get rid of updraft area fraction boundary conditions and switch to using total energy in the updrafts.
Cost/Benefits/Risks
The benefit is a better behaved scheme that can be efficiently coupled with implicit timesteppers and ClimaAtmos as a whole. The risk is that our EDMF scheme depends heavily on the filters, etc. The changes of boundary conditions and filters will most likely lead to changes of EDMF results. It would be great to know if the anticipated changes in EDMF results could be fixed by ML calibrations. However, right now we don't have a calibration pipeline hooked to TC+CA.
[ ] Improve the plotting pipeline in the CI (Plots -> Makie?)
[ ] EDMF relevant output from spherical runs
Stretched grid testing
[ ] Check if we can have initial condition profiles that are discrete hydrostatic for SCM EDMF. (Can we use initial condition from ClimaAtmos moist baroclinic wave for this test?)
[ ] Add stretched grid tests for SCM EDMF. (Can we use initial condition from ClimaAtmos moist baroclinic wave for this test?)
Known issues following different non-linear filters and hacks (this is related to old EDMF, not EDMFX
[ ] Replace the LBF operators and velocity clipping by ClimaAtmos vertical_transpor. (To be used instead of gradient(LBF(Ic(CG.Wector)))). This can be done even when we are still clipping the negative velocities in EDMF.
[ ] Refactor precipitation advection for 1-moment microphysics scheme.
[ ] Try replacing edmf grid with ClimaAtmos coordinates.
[ ] EDMF column loops (real_center_indices): Can we get rid of them? How does that affect performance.
Purpose
We want to refactor EDMF code in ClimaAtmos.jl. Currently EDMF is filtering based on the updraft area fraction, updraft vertical velocity and to ensure tracer positivity. We want to replace some of those filters with regularisations, change the way we handle boundary conditions, delete the unnecessary filters and move what we can to the tendency evaluation. We also want to use ClimaCore/ClimaAtmos advection operators, get rid of updraft area fraction boundary conditions and switch to using total energy in the updrafts.
Cost/Benefits/Risks
The benefit is a better behaved scheme that can be efficiently coupled with implicit timesteppers and ClimaAtmos as a whole. The risk is that our EDMF scheme depends heavily on the filters, etc. The changes of boundary conditions and filters will most likely lead to changes of EDMF results. It would be great to know if the anticipated changes in EDMF results could be fixed by ML calibrations. However, right now we don't have a calibration pipeline hooked to TC+CA.
People and Personnel
Results and deliverables
A better behaved EDMF scheme suitable for implicit single column simulations https://github.com/CliMA/ClimaAtmos.jl/milestone/4
Task Breakdown And Tentative Due Date
CI updates
Testing EDMF IMEX simulations
Documentation (@tapios, @trontrytel, @szy21, @dennisYatunin)
Setup Bomex box experiment with EDMFex (@nefrathenrici, @dennisYatunin, @trontrytel, @szy21 )
Delete update aux (@trontrytel, @dennisYatunin)
Physics testing. (@trontrytel, @szy21)
Calibration pipeline. (@nefrathenrici, @costachris )
Output, diagnostics
Stretched grid testing
Backlog / known bugs
Known issues following different non-linear filters and hacks (this is related to old EDMF, not EDMFX
real_center_indices
): Can we get rid of them? How does that affect performance.getindex
? One of the main blockers is: #887 and https://github.com/CliMA/ClimaCore.jl/issues/77Proposed Delivery Date
...
CC
@cmbengue @simonbyrne