# 01.09.2022 ICON Librarization

## Goal:
Split ICON into several parts ("granules") that can be tested, run independently.

* prototypes for granules:
- graupel microphysics (does not use t_patch)
- advection (uses t_patch): t_patch

## t_patch
Contains the grid, but also much more:
- communication patterns, connectivities.
-

`p_patch`:
- can be viewed as tree, but every branch brings in something new.
- depends heavily on configuration, but only initializes part. So there are a lot of null pointers, that might accidentially be accessed, because they are not hidden.

## wording
*granules*: physics specific components like graupel, advection...

## granules:
should have their own CI, independent tests (called serialization tests: read in model data and diff result, no physical meaning, only one timestep) ...

What is a "granule":
`A model part that can be switched "ON"/"OFF" via namelists.

`

- graupel
- dyn core (?)
- advection (Horizontal, Vertical)
- land-surface (JSBACH)
- radiation (RTE-RRTMGP) , ecrad
- aerosol chemistry
- turbulance
- Sat (uration) ad(justment)

### open, should those be a granule?
- math utilities => library that requires
- Grid Manager (and therewith everything below)
- t_patch

?? where to draw the line between granules

# 02.09.2022

### GOALS of librarization
WILL: copy less code in the granules
EXCLAIM/GT Forpy/ (Mauro): make interfacing into python workflow easier

## Structure of the code:

- see slide by Jonas
- Idea: make as many pieces ICON agnostic that are possible. Some shared stuff depends on ICON stuff but really need not
- split modules into smaller modules

*There is some reluctancy of moving things around, rearranging modules, renaming... that should'nt be.*

## proposal for hackathon
- use includes for performance critical (or often used) stuff, such that it can be inlined by the compiler
- remove icon specific code from as many modules as possible.
- examples see slides by Jonas
- pack modules (utils) that are used from several granules into libraries, such that they can be used by different granules without duplication.
- clarify: is there going to be one giant "utilities" library or should the be split up into several libraries that can be used as needed
- p_patch: refactor: replace by a GridManager where the needed fields/indices can be retriefed. Use fx `get_index_xx` functions instead of accessing and passing the entire structure.
- interfaces should expect mostly "simple" fields, not complicated Fortran structures

* [ ] model driver
* [ ] dy core driver