# [Greenline] vertical grid coordinate
<!-- 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 -->
The exclaim experiments use the `SLEVE` terrain following coordinate (`ivctype` == 2) . See
- ICON tutorial, section 3.4
- Schär, C., D. Leuenberger, O. Fuhrer, D. Lüthi, and C. Girard, 2002: A new terrain-
following vertical coordinate formulation for atmospheric prediction models. Mon.
Weather Rev., 130, 2459–2480.
Referential heights for each model level are encoded in tow `KDim` fields in ICON eference called `vct_a` and `vct_b` those are used throughout the model for computations.
In `icon4py` we currently read these fields from serialized data.
In ICON `vct_a` and `vct_b` are either read from file (reference files are in
`icon/vertical_coords_table`) or are computed at model setup. and are governed by a couple of namelist parameters from `sleve_nml`
Together with `vct_a` and `vct_b` the computation of `nflatlev` and `nflatlev_gradp` should be adressed.
## Appetite
<!-- Explain how much time we want to spend and how that constrains the solution -->
1 cycle
## Solution
<!-- The core elements we came up with, presented in a form that’s easy for people to immediately understand -->
Computation of the `vct_a` and `vct_b` are determined by a couple of namelist parameters in
`slevel_nml`.
EXCLAIM experiments use the `SLEVE` coordinate and `itype_laydistr = 1` that is a stretched cosine function.
The corresponding calculation of `vct_a` and `vct_b` and parameters that depend upon them should be ported to python: see `mo_init_vgrid.f90: init_sleve_coord, prepare_vcoord`
### icon4py
see `icon4py-common`: `vertical.py`.
Add needed namelist parameters to the config class, with the default values given in `mo_slevel_nml.f90`
- `nshift_above_thcklay ` : can be left out and set to 0, no experiments overwrites that value
- `itype_laydistr == 1` : everywhere. The other options (not currently used by EXCLAIM) can be added if needed later.
-
```python
class VerticalGridConfig:
(...)
lowest_layer_thickness:float = 50.0 (aka min_lay_thckn )
maximal_layer_thickness: float (aka max_lay_thckn)
top_height_limit_for_maximal_layer_thickness = (aka htop_thcknlimit)
top_height:float = 23500.0
stretch_factor: float = 1.0
class VerticalParams:
(...)
vct_b
```
- add `vct_b` to `VerticalModelParams`
- `vct_a` is currently passed as parameter into the constructor. If not passed, it should alternatively be upon construction from the namelist parameters according to `init_sleve_coord`. Passing as a parameter can be used if it is read from file or serialized input.
- compute `nflatlev` and `vct` from `vct_a` and `vct_b`
Computation can be tested against serialized `vct_a`, `vct_b`, `nflatlev`
add a `__str__` function that can be used to write the VerticalModelParams to log. (see ICON run logs or `print_vcoord_info`)
## Rabbit holes
<!-- Details about the solution worth calling out to avoid problems -->
leave out `init_vert_coord` which computes the full heigth fields, since we have no terrain yet.
This is exactly what Jacopo started in a `port_z_ifc` branch.
This being a rabbit hole, it also requires (apparently even for analytically smooth hills) topography smoothing routines from `mo_process_topo`.
## 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] Port v_grid which computes `vct_a`, `vct_b`
- [ ] Port init_vert_coord
- [x] Computation of `z_ifc`
- [ ] Computation of topography smoothing
- [ ] Actually use all this stuff to compute metrics and derivatives
- [x] `vct_a` and `vct_b`
- [ ] `z_ifc`
- [ ] rearrange the `icon4py_driver.initialization` of the testcases such that there is only one `if (jabw/gauss/serialized):` which reads the grid, generates topography, generates ICs etc (rather than how it's done now with `if`s hidden in specific methods for the above functions)