# [Greenline] Model Configuration - Research

<!-- Add the tag for the current cycle number in the top bar -->

- Shaped by: Magdalena
- Appetite (FTEs, weeks):
- Developers: <!-- Filled in at the betting table unless someone is specifically required here -->

## Problem
<!-- The raw idea, a use case, or something we’ve seen that motivates us to work on this -->
In ICON4py each model component currently has its own Configuration `dataclass`. They are generally immutable classes that contain the configuration parameters (supported namelist options) for the component. Those classes need to be instantiated by the user in Code.

This approach was chosen for a simple fast first initialization of the component but is not very flexible as we move towards more complex model runs.

Additionally some more runtime specific parameters as the device type and backend can be set through environment variables which is used for the `py2fgen`

As the model grows, it is time to consolidate and implement a more unified view of configuration handling.

In this project we want explore the requirements for model configuration and evaluate which approach or tool supports those best.

## Appetite
<!-- Explain how much time we want to spend and how that constrains the solution -->

## Solution
<!-- The core elements we came up with, presented in a form that’s easy for people to immediately understand -->
There exist a couple python of libraries and frameworks that offer hierarchical configuration handling and should be explored during this project.

- [omegaconf](https://omegaconf.readthedocs.io/en/2.3_branch/)
- [hydra](https://hydra.cc/docs/intro/) uses omegaconf,
- [dacite](https://github.com/konradhalas/dacite) used by NOAA, NASA (very simple library that facilitates dataclass <-> dictionary handling
- [NDSL](https://github.com/NOAA-GFDL/NDSL/tree/c52a719af75882752079331abe3ad8ad8dd3e386/ndsl) middleware developed used by NOAA/NASA

The approach should allow
- an easy reproduciability of a specific model run and it configuration
- allow for "distributed" configuration where each components specific parts can be kept in the components package, while the handling of it is centralized.
-

## Rabbit holes
<!-- Details about the solution worth calling out to avoid problems -->
Do not try to replicate any workflow and data processing platform. KISS.

## 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