# Green line: Python Diffusion and simple driver

###### tags: `functional cycle 13`

Developers: Magdalena, Nikki (second half of cycle)

Appetite: full cycle

## Goals
### Diffusion
#### Enable exchangeability of Fortran and GT4Py diffusion granule

Align interface with Fortran Diffusion granule (Will).
Call the Fortran granule from a python driver and vice versa.
- align interface with [Will Fortran granule](https://gitlab.dkrz.de/icon/icon-cscs/-/blob/diffusion_granule/src/atm_dyn_iconam/mo_nh_diffusion_new.f90#modal-confirm-fork-webide)
- [x] move parameters from `interpolation_state` and `metric_state` to `init` (they supposedly do not change during model run)
- [x] move `p_patch` fields to `init`
- [ ] (optional) recalculate `metric_state` fields from`mo_vertical_grid.f90:prepare_zdiffu`

- [x] generate Fortran bindings with low level interface to python diffusion, such that we can call python dycore from a Fortran driver.
- [ ] how to handle dsl specific fields:
- [ ] interface shallow Fortran derived types to python (like geographical coordinates),
- [ ] re-ordering of dimensions in sparse fields.
- [ ] integrate into ICON, call from Fortran

#### readability refactoring
- [x] rename diffusion stencils
- [x] identify names with Anuragh
- [x] rename stencils
- [x] merge in icon4py and icon/exclaim
- [ ] and fused diffusion stencils
- [x] identify names
- [x] rename stencils
- [ ] merge into icon4py and icon/exclaim

#### optional: manual halo exchanges
Add manual halo exchanges in python diffusion implementation. As first step towards a multi node model we want to add manual halo exchanges in the python diffusion.

Currently only mpi4py is ready for usage in the pure python models. So implementation must start with mpi4py.

- [ ] implement halo exchanges in mpi4py
- [ ] investigate what we want to use in the long run: mpi4py, GHEX, yaxt.
- [yaxt](https://gitlab.dkrz.de/dkrz-sw/yaxt/-/tree/master) at a first glimpse there are no python bindings and it runs on top of and has no special GPU support? (Ask Will)
- current version of yaxt uses Fortran pointers to access communicators, etc.
- ICON-C plans to use yaxt everywhere, to this goal they (Who: DKRZ, Panos) they work on a version where Fortran pointers are replaced by integer identifiers.
- there are no python bindings.
- [ghex](https://github.com/ghex-org)
- Python bindings only for Cartesian, for unstructured they are not yet ready. (Who: Till, Mauro)

### simple python driver
Python main function that does:
- [x] logging
- [x] (load) configuration (dummy version, only mch_ch_r04b09)
- [x] initialize the grid (from ICON-serialized serialbox data)
- [x] read-in initial data fields (from ICON-serialized serialbox data)
(this can all be done from serialbox data).
- [x] starts a time loop that does some dummy timestepping and runs diffusion and does a dummy time stepping
- possible timestepping: read in a new serialized init-savepoint at very timestep
- ~~implement timestepping scheme (same as in icon)~~

### Implement rest of dycore as Python Granule

everything in `mo_solve_non_hydro.f90` under `SUBROUTINE solve_nh`
- [ ] mo_solve_non_hydro.f90: solve_nh
- [ ] velocity advection: `mo_velocity_advection.f90`