ft: rcemipii vertical mesh

[haakon-e]

This pull request introduces support for selecting a predefined vertical mesh in the model configuration, specifically enabling the use of the "rcemipii" vertical mesh. The changes allow users to specify a vertical mesh type in the configuration files, and the codebase is updated to construct the appropriate mesh based on this setting.

Vertical mesh configuration and support:

• Added a new vertical_mesh configuration option in default_config.yml to allow users to select the predefined "rcemipii" mesh.
• Updated the rcemipii_box_CRM_1M.yml model configuration to use the new vertical_mesh: rcemipii option, and adjusted related vertical grid parameters (z_max, z_elem) to match the new mesh.

Codebase enhancements for mesh construction:

• Modified the BoxGrid function in grids.jl to accept a vertical_mesh argument and construct the "rcemipii" mesh when specified, using a hardcoded boundary layer and uniform spacing in the free atmosphere.
• Updated the get_grid function in type_getters.jl to pass the vertical_mesh parameter from parsed arguments to the grid constructor.

[haakon-e]

This change is part of the following stack:

• ft: rcemipii vertical mesh #4172 ◀
  • rcemipii testing #4213

_{Change managed by git-spice.}

[haakon-e]

cc: @oalcabes

[szy21]

I'm not sure if it's a good idea to specify predefined meshes for different setups. It may be ok if we just add RCEMIP, but what if someone wants to add more specific setups in the future? If we do want to support this, I think it would be better to add the functionality to read an array of numbers for the vertical mesh from yaml.

This is just a thought, I would be interested in what others think.

[haakon-e]

yeah I agree. I am hoping I can wait until Nat gets the new interface merged so that I can (hopefully) define the mesh only in my simulation setup instead of "polluting" the shared simulation setup functions

[haakon-e]

Closed. Equivalent features implemented in #4236