# [Blueline] Preparing icon-exclaim for inclusion into icon/icon + AMD port
<!-- VEB Optimizer -->

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

## Problem
Last cycle we did initial work on merging `icon-nwp:main` into `icon-exclaim:icon-dsl` and preparing for an AMD port of a simple ICON experiment. The latter effort was stymied by to length of the new timers for the Dycore granule, meaning the code is not Fortran-compliant and does not compile with gfortran.

We would now like to prepare icon-exclaim for inclusion into the main gitlab.dkrz.de/icon/icon; the first step would be to allow CPU compilation with compilers other than nvhpc, e.g., gcc and Intel.
To that end one option would be to get icon-exclaim running at least on CPU on Beverin (AMD) using gcc, proving that the icon4py integration works not only with nvhpc. This will require a PR to `icon-exclaim:icon-dsl` to shorten kernel names and thus also the timer names.

One candidate for writing the interface between Fortran and Python is the existing "Community Interface" (ComIn). Another candidate is the already existing py2fgen.

Another optional goal is to support all dycore and diffusion namelist parameters except nesting. This will require to at least translate two more stencil and integrate them into the combined stencils with if conditions.

## Appetite

Full cycle if needed as upstreaming ICON is the highest priority for the cycle.

## Solution

The plan is to get icon-exclaim even closer to the icon/icon code base. We can also change certain things in icon/icon such as order of sparse dimensions for sparse fields which will be accepted upstream. Also we should set up a system for more frequent updates from the gitlab.dkrz.de/icon repository.

Finally, we open a PR on icon/icon with the py2fgen based integration of ICON4Py including a documentation on how to build the ICON4Py enabled ICON.

In the discussion with the reviewers we need to figure out if we upstream:
- everything (bindings, online verification, serialization hooks)
- bindings + online verification
- only bindings

If there is push-back from reviewers on integrating everything, we go with only bindings in a first step (as this would satisfy the cycle priority).

### Optional: ComIn
We also plan to use ComIn to incorporate the GT4Py-dycore. Extensive discussions have already happened with Nils Dreier (DKRZ) and Florian Prill (DWD) about this possibility, and they are enthusiastic that incorporating in dycore would illustrate the potential of ComIn, particularly w.r.t. its Python bindings. Nils already has a prototype example that we need to review.

### Optional: Support full dycore namelist
We could add all missing dycore and diffusion namelist options except nesting. This might improve community acceptance of our dycore, if these options are used by some people.

## Rabbit holes
<!-- Details about the solution worth calling out to avoid problems -->

We are counting on the help of Nils and Florian for the ComIn aspects. If we don't get the expected help, we might have to go down the ComIn rabbit hole.

Not clear how much we will focus on AMD, but Beverin is currently instable and the tool chains there immature.

## No-gos
No wasting time on the spack-c2sm based compilation.

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

- [ ] Get CPU version of icon-exclaim with other compilers
- [ ] Compilation with GCC on Santis/Beverin
- [ ] Compilation with Intel on Levante
- [ ] ComIn collaboration with Nils and Florian
- [ ] Review of Nils prototype python binding
- [ ] Help define list of needed modifications to ComIn
- To review for DWD
- [ ] Swapping of velocity advection tendencies for dycore is outside of dycore in icon-nwp
- [ ] Swap dimensions of all sparse fields in dycore which are not (horizontal, blocks, sparse) or (horizontal, vertical, blocks, sparse)
- [ ] `vertidx_gradp`, `zdiff_gradp`, `coeff_gradp`
- [ ] RBF coeffs
- [ ] Also attempt to change if you encounter %v1 and %v2
- [ ] `primal_normal_cell%v1/2`, `dual_normal_cell%v1/2`
- To change on our side
- [ ] What to do with icon4py serialization utilities utilizing serialbox
- [ ] Move creation of DSL specific fields (such as masks instead of lists) into the icon4py startup functions
- [ ] `wgtfacq_c_dsl`
- [ ] `wgtfacq_e_dsl`
- [ ] `mask_prog_halo_c_dsl_low_refin`
- [ ] `zd_diffcoef_dsl`
- [ ] `zd_intcoef_dsl`
- [ ] `zd_vertoffset_dsl`
- [ ] `mask_hdiff`
- [ ] `pg_edgeidx_dsl`
- [ ] `pg_exdist_dsl`
- [ ] Add missing dycore and diffusion namelist options (everything except nesting)
- [ ] igradp_method requires 2 more stencils
- [ ] lhdiff_smag_w in diffusion requires 1 stencil
- [ ] Ensure all namelist options that are accepted are supported and the ones rejected return good error messages
- [ ] Aim for all buildbot tests green of all supported namelist switches