# ICON-EXCLAIM and gt4py

## gt4py vs icon4py
*`gt4py` is a general tool for weather and climate equation descriptions*

*`icon4py` is an implementation of ICON using `gt4py`.*

Hence, `icon4py` might drive development of features in `gt4py` but nothing icon specific should lead into `gt4py`.

## gt4py
- reduction over all(horizontal and vertical) dimensions `f(Field[[KDim, HDim]:float]) -> float` needed in velocity advection -> try this out.

## icon-exclaim

### Blue Track
- ICON modularization (pure Fortran), (in collaboration with ICON-C)
- ICON-exclaim with gt4py stencils
- ICON-Exclaim with fused gt4py stencils.
- `icon4pygen` that provides Fortran bindings for `gt4py` stencils

### Green Track
- python standalones/ granules
- python driver for granules
- start with driver for dycore
- eventually end up with full python model

### questions

- Interoperability of green and blue track:
- call Fortran granules from Python driver?
- *Allow granules that have not yet been ported to be used*
-

- call Python granules from Fortran driver?
- *Testing*, should we use offline or online verification, or both?
- *Use icon grid setup, communicators from original Fortran Code*

- at which level should that interoperability be? F.ex. driver calls a granule from the other track, or do different drivers hand off to each other? F.ex. fast process to slow process? (Don't know whether this makes a difference.)

-> need to generate Fortran bindings for python granules and python bindings for Fortran standalones.

- Green Track:
- what configuration parameters should be supported? Is there a list of parameters (namelist switches, experiments...) that exclaim wants to support? If not should we set compose that? So far we *only* test 1(+) experiment. David's Aquaplanet is built after that one. Same applies for blue track (icon-exclaim)...

- gt4py vs icon4py:
- icon grid should be part of icon4py. Stencils on subdomains are handled with regular argument and index fields, f.ex.

    def func(vn:Field[[...], float], index_field:Field[[...], int], start_index:int, end_index:int):
        vn = where(index_field >= start_index and index_field < end_index, ..., vn)

are there other options? Like an interface provided by gt4py that needs to be implemented by each model?
- halo exchanges: are they done in python in python or in gt4py? How do we make them part of gt4py without leaking grid and topology.

# coordination meeting Jan, 12th

present: Mauro, Hannes, Anurag, Magdalena, Will

# Next steps
- go through diffusion parameters, which parameters/ experiments are necessary. -> Magdalena, Anurag (potentially, find a useful experiment with diffusion only)
- readability improvement refactoring for diffusion (fused stencil renamings): -> Magdalena, Christoph, M. Anuragh
- interoperability: bring together Fortran, python interface
- port dycore and fulldriver (include I/O, timestepping)(higher priority for Anurag than the halo exchanges)
- first manual halo exchanges
- gt4py: structure arguments for grid parameters

## outcome
- relevant code branches and configuration of diffusion to determine what is relevant for exclaim: -> **Magdalena, Anurag next Wednesday, Jan 18th**

- useful test case, experiment for diffusion standalone only. -> **Anurag** will think about, whether there exists something like that.

- 1st round of readability refactoring should involve renaming of (fused) stencils to something more meaningful -> **Magdalena, Christoph, Anurag** (I will coordinate this)

- long argument lists, boundary domain arguments: the idea is to handle this gt4py struct-arguments which can contain the part of the grid needed (**future gt4py work**)

- halo exchanges: should eventually be generated from gt4py, first experiments will be done with manual in python. -> **icon4py work** and **gt4py work** (possible candidates: pure mpi4py, ghex, yaxt)

- time stepping, full dycore driver: includes (proper) IO, and porting of other dycore model. -> **icon4py work.** Has higher priority to Anurag than halo exchanges (deliverable for Q3), but these can also be attacked in parallel.