# [Greenline] Preparation of microphyiscs schemes for warm bubble experiment

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

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

## Problem

Our plans include a Greenline warm bubble experiment by the end of 2025. This would necessarily require a microphysics scheme written in GT4Py. We currently have two:

1. `model/atmosphere/subgrid_scale_physics/microphysics`: NWP microphysics
2. `model/atmosphere/subgrid_scale_physics/muphys`: Microphysics by Bjorn Stevens, *"Muphys"*

Neither of these schemes is truly ready for inclusion into icon4py:

1. NWP microphysics is scheme we target, but so far it has only been run with the embedded backend. The main implementation is on a `icon4py` branch. Additionally, it consists of one very long `scan_operator`, which possibly will not perform well.
2. MuPhys is the scheme used in climate runs at MPI-M; many different implementations (SYCL, Kokkos, OpenMP, GT4Py, ...), have been evaluated. A small test problem runs with embedded, larger test problems with `gtfn_cpu` and `gtfn_gpu`, but the performance is poor, perhaps 2 orders of magnitude too slow. It has many `where` statements and two small` scan_operator`.

We would like to have at least one of these schemes in a state where it could realistically be incorporated into the warm bubble experiment. This requires some preparation to assess the viability of each.

Our first choice would be to use NWP microphysics. If for some reason it would not be usable, MuPhys could be a fallback solution.

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

1/2 FTE for each of the schemes; this might require also participation from the GTFN and DaCe teams (both busy), which might significantly constrain the progress.

## Solution

The two schemes are in different phases of development.

1. NWP Microphysics needs some improvement to run within a standalone. It then needs to be merged into the main icon-dsl branch. Then it should be evaluated using both the GTFN and DaCe backends. Only then can we assess the problems which stand it the way. It is possible that these backends will entail problems, which might require a full rewrite; in this cycle we would try to map out what the rewrite would look like.
2. MuPhys performs poorly with `gtfn_cpu/gpu` and not at all with `dace_cpu/gpu`; we would like to iterate with the backend experts to understand how to work around these problems. Workarounds in the implementation are possible, e.g., the six Newton-Raphson iterations will not currently compile with gtfn in reasonable time, but fewer iterations would be possible.

## Rabbit holes

1. The intention is definitely *not* to reimplement NWP Microphysics at this time
2. The intention is not to overload the backend teams, but rather for them to make suggestions of how we might work around current problems with modifications to the code.

## No-gos

No rewrite of NWP Microphysics.

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

- [ ] NWP Microphysics ([PR#537](https://github.com/C2SM/icon4py/pull/537)
- [ ] Run branch again within standalone
- [ ] Review PR and merge into `icon-dsl` main branch
- [ ] Evaluate with `gtfn_cpu/gpu` ; discuss problems
- [ ] Evaluate with `dace_cpu/gpu` ; discuss problems
- [x] muphys
- [x] For `gtfn`, get input from Till/Hannes, implement workarounds if possible
- [x] For `dace`, get input from Philip, Eduardo, implement workarounds, if possble
- [ ] Sketch of NWP Microphysics rewrite, if needed
- [ ] Subtask L
- [ ] Subtask S