# [Blueline] (Py2F cont) Dycore verification, CI/CD on alps/balfrin

Continuation of: https://hackmd.io/7Djwh70mSOqrf2_1mZiEuw

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

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

## Problem

Currently missing:
* Dycore granule verifying and probtesting
* CSCS CI for granule build on balfrin/santis utilizing uenv is missing
* Overhead optimization

## Appetite
1 cycle

## Solution

#### Dycore granule
- Verify and probtest the dycore granule (GPU, CPU).

- Ensure we can execute experiment with both granules integrated at the same time.

#### CSCS CI on Balfrin/Santis
- Change `create_target_header` to auto-generated all runscript configurations which are currently added by hand

- CSCS CI on balfrin/santis
- verification mode (compare granule at every execution to Fortran)
- substitution mode (only execute icon4py granule, probtest)
- Switch from mch_ch_r04b09 to small production experiments of MCH (icon1, icon2, kenda1)

#### Parallel Runs

1. There should be datatests in place on the icon4py side which are able to test parallel runs.

#### Overhead optimization

1. Create dictionary with re-usable GT4Py fields for both `now` and `new`, so we can get rid of overhead of constructing fields at every timestep. Be aware of swapping pattern of the dycore.

#### ITIR -> dace
- Test the (ITIR -> dace) backend instead of (ITIR -> gtfn)

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

## No-gos

## Future cycles

## Progress