# [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)