Port z ifc #564
Port z ifc #564
Conversation
…st for topography
|
cscs-ci run default |
|
launch jenkins spack |
…ate related tests
* move dycore stencils to sub packages stencils --------- Co-authored-by: Enrique González Paredes <enriqueg@cscs.ch>
* filter out unused connectivities * remove diffusion_instance fixture * update member blacklist in Diffusion.orchestration_uid
| f"Model top is too low. But num_levels, {vertical_config.num_levels}, <= 6. " | ||
| ) | ||
|
|
||
| return gtx.as_field((dims.CellDim, dims.KDim), z3d_i) |
There was a problem hiding this comment.
Can you reflect this in the code, by splitting into functions with good names? At least I would split what you do in init_vert_coordinate into 2 functions, one which computes the height (down to here) and another one that does this layer thickness thing that comes from here on. Then the init_vert_coordinate calls both of them.
def init_vertical_height_field(...)-> Field[Dims[CellDim, KDim], wpfloat]:
z_3d = compute_height_from_idealized_flat_heights_and_topology(vct_a, topology):
z_3d = correct_layer_thickness(...)
z_3d = check_flatness_of_flat_layer()
return z_3d
This is some pseudo code. (I don't even know what would be a proper name for the vct_a compared to the z_ifc...) The idea that I want to transport is, suppose I read icon4py code then depending on what interests me I am happy with seeing somewhere compute_vertical_height_field, I know what is happening in the function and go on (supposedly that the function does this and only this). If I am interested in the height field, then I can jump into the function and I see that 1. it takes contribution from topology and vct_a, 2. there is something to take into account of the thickness of the resulting layers, 3. the previously (or configured) flat layer needs to still be consistent. May that is all that interests me. So I go on. Only if I need to know how the thickness of the minimal layers is determined I need to jump further down into the 2nd of these functions. Otherwise the reader does not need to care of the gritty details of indices and fields and dimension and etc.
Good code transports meaning and it is always organized in different levels of abstraction or details. Such that a reader can ignore the details if he does not need them.
And you write code once and you read it 1000 times...
This is one of the reasons why ICON code is so hard to understand that there is (almost) no level in the code above the most detailed one. If I want to see what algorithm they use they throw 3 nested loops at me. From these I need to make sense what relations ship they are computing.
… buffering (#602) Refactor and expand the model/common/utils module with simple implementation of utilities for to double-buffering like Pair. Additionally, fix the existing doctest for chainable.
|
cscs-ci run default |
|
launch jenkins spack |
|
Mandatory Tests Please make sure you run these tests via comment before you merge!
Optional Tests To run benchmarks you can use:
To run tests and benchmarks with the DaCe backend you can use:
In case your change might affect downstream icon-exclaim, please consider running
For more detailed information please look at CI in the EXCLAIM universe. |
|
cscs-ci run default |
|
launch jenkins spack |
Currently not working, possibly because of a gt4py issue related to
C2E2CO(GridTools/gt4py#1583)