# [Greenline] Implementation of itime_scheme=6 <!-- Add the tag for the current cycle number in the top bar --> - Shaped by: Chia Rui - Appetite (FTEs, weeks): - Developers: ## Problem Currently, only itime_scheme=4 is implemented in icon4py. itime_scheme=4 is widely used for its optimal efficiency. However, it is not the truly predictor corrector scheme. Many diagnostic computations in the dycore is skipped and reused (which is also why we need to swap the buffer). Here, I feel that there is a need to implement itime_scheme=6 and investigate the accuracy loss when choosing itime_scheme=4. Moreover, a performance boost as guaranteed by using gt4py can possibly cover up the extra computational cost in itime_scheme=6. Only a few more computations or stencils need to be added in ```SolveNonhydro.time_step```. I list down those extra stencils below. ## Appetite <!-- Explain how much time we want to spend and how that constrains the solution --> ## Solution ### Computations to be added for itime_scheme=6 <!-- The core elements we came up with, presented in a form that’s easy for people to immediately understand --> There is no need to swap ```ddt_vn_apc``` and ```ddt_w_adv```. ```lvn_only``` is always False. Below are the extra computations that need to be executed when itime_scheme=6. - ```vt``` Update of tangential wind at the edge center and full level. It should be added between corrector stencil 31 (_compute_avg_vn) and corrector stencil 32 (```_compute_mass_flux```). - ```z_w_concorr_me``` Update of contravariant correction at the edge center and full level. It should be added right before corrector stencil 41 (```_compute_divergence_of_fluxes_of_rho_and_theta```). - ```z_w_concorr_mc``` Update of contravariant correction at the cell center and full level. It should be added right before corrector stencil 41. - ```w_concorr_c``` Update of contravariant correction at the cell center and half level. It should be added right before corrector stencil 41. ### Clean-up suggestion (Please ignore now) Currently stencils are written according to their order in Fortran ICON. And they are combined in a more performance or software-engineering oriented way but not considering the scientific purpose of the computation or how to make it more understandable by domain scientists. I would suggest rearranging and regrouping them with more scientific meaning. For example, in the predictor step, ```python= update_diagnostic_variables(("normal_wind_at_interface", "tangential_wind", "vorticity", "contravariant_correction"), diagnostics, vn, w) ( z_rth_pr_1, z_rth_pr_2, ... ) = compute_local_variables(vn, theta_v, rho, ...) velocity_advection(diag.ddt_w_adv, diag.ddt_vn_apc, vn, diag.vn_ie, diag.vt, diag.zeta, w, diag.w_concorr_c, lvn_only) # maybe diag.ddt_w_adv, diag.ddt_vn_apc should only live within SolveNonhydro ( z_rho_e, z_theta_v_e, ) = miura_flux(z_rth_pr_1, z_rth_pr_2, vn, diag.vt) z_gradh_exner = horizontal_pressure_gradient(z_exner_ex_pr, theta_v, theta_v_ic, z_rth_pr_2, z_theta_v_pr_ic) new_vn = horizontal_momentum(diag.ddt_vn_apc, z_gradh_exner, z_theta_v_e, diag.ddt_vn_phy) new_w = vertical_momentum(...) ``` Renaming of local variables also needs to be done. Some local variables in ```solve_nonhydro``` and ```velocity_advection``` are difficult to understand at first glance. For example, ```z_rth_pr_1``` -> ```perturbed_rho``` ```z_rth_pr_2``` -> ```perturbed_theta_v``` ```z_theta_v_pr_ic``` -> ```perturbed_theta_v_at_interface``` ```lvn_only``` -> ```skip_vertical_advection``` ## Rabbit holes <!-- Details about the solution worth calling out to avoid problems --> ## No-gos <!-- Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the ## appetite or make the problem tractable --> ## Progress <!-- Don't fill during shaping. This area is for collecting TODOs during building. As first task during building add a preliminary list of coarse-grained tasks for the project and refine them with finer-grained items when it makes sense as you work on them. --> - [x] Task 1 ([PR#xxxx](https://github.com/GridTools/gt4py/pulls)) - [x] Subtask A - [x] Subtask X - [ ] Task 2 - [x] Subtask H - [ ] Subtask J - [ ] Discovered Task 3 - [ ] Subtask L - [ ] Subtask S - [ ] Task 4