---
# System prepended metadata

title: '[Greenline] [Greenline] Naive user''s experiences with GT4Py for Physical Parameterizations'

---

# [Greenline] Naive user's experiences with GT4Py for Physical Parameterizations

## Context

The **muphys** cloud microphysics, originally written by Bjorn Stevens (MPIM), but rewritten elegantly in C++ by Georgiana Mania, et al., is being ported to GT4Py.

The microphysics basically updates the temperature and water content of the constituent species -- vapor, cloud, snow, ice, rain, graupel -- in every atmospheric cell through one time step, taking the transitions of species, e.g., vapor to snow, into account. Most of the calculation is cell-based, except for a two vertical passes from upper atmosphere towards the surface to calculate the precipitation in the time step.

Subsequently we relate our experiences porting the code and try to answer some of the following questions:

* Is the GT4Py implementation as elegant as the platform-portable Kokkos implementation?
* Are there possible improvements to GT4Py which could make the implementation more succinct?

These are only the views of a naive first-time GT4Py user, who perhaps does not yet see a much better and succinct implementation.

## Executive Summary

* The good news: GT4Py facilities already cover most of the requirements for such cell-based microphysics with vertical scans (!)
* Parameterizations like muphys have lots of IF statements, which are basically testing if cell values are above/below certain thresholds.  These can generally be well formulated with `where` statements
* There is still room for improvements
    * muphys uses loads of empirically determined constants: these are currently passed as into the `field_operator` as arguments. A more direct mechanism would be better.
    * It would be nicer to implement the cell operators as abstract `field_operator`s working directly on scalars.  Higher level operators would work on `CellKField` fields, and calls to scalar operators would be recast as fields.
    * It is not clear when` program`s should be used.  Can't we mostly use `field_operator`s?  Also the need to pass temporary arrays to program is inelegant. The program adds a lot of boilerplate, which could perhaps be avoided.
    * The directory structure `model/atmosphere/subgrid_scale_physics/muphys/src/icon4py/model/atmosphere/subgrid_scale_physics/muphys/` seems excessive. It is much simpler in the `muphys-cpp` implementation.

## Examples

* Intricate IF statements.  How to make the GT4Py implementation more elegant?
* Vertical scans with `field_operator` calling `scan_operator` calling `field_operator`.
* 



