Remapping IBD with CDO

Initial/Boundary Data
1

Hi all, as CDO is recommended as remapping initial and boundary data, I tried to set this up. But I do have some questions. First, how do I remap?

1. generate weights:
cdo -f nc4 gencon,${TARGET_GRID}:${N_TARGET} -selname,cell_area ${SOURCE_GRID} ${WEIGHTS}

2. remap IBC:
cdo -f nc4 remap,${TARGET_GRID}:{N_TARGET},${WEIGHTS} -chname,HHL,z_ifc - selname,{FIELDS} -setgrid,${SOURCE_GRID}:{N_SOURCE} ${DATADIR}/${outdatafile}_lbc.nc

Now, the name of model levels and half levels after remapping ICON-EU focing data with cdo
can differ (depending on the forcing data):

dimensions: of iefff00000000.2024021612
time = UNLIMITED ; // (1 currently)
cell = 51212 ;
nv = 3 ;
height = 75 ;
bnds = 2 ;
height_2 = 74 ;
height_3 = 75 ;

dimensions: of iefff00000000.2024021615
time = UNLIMITED ; // (1 currently)
cell = 51212 ;
nv = 3 ;
height = 74 ;
bnds = 2 ;
height_2 = 75 ;
height_3 = 75 ;

Here, height and height_2 are swapped. Could this result in an icon simulation problem using files with different dimension names for model levels? Using iconremap

dimensions:
time = UNLIMITED ; // (1 currently)
ncells = 51212 ;
vertices = 3 ;
height = 75 ;
bnds = 2 ;
height_2 = 74 ;
height_3 = 75 ;

height_2 is always used.

Furthermore, cell and nv are used after cdo and ncells and vertices after iconremap. Should these be renamed with ncrename from nco or can ICON handle this? I am running simulations on icon 2024.10 and 2025.10.

So, my question:

  • Can the use of the different name (height / height_2) for the model level be a problem in an icon simulation?
  • Should cell and nv be renamed to ncells and vertices or can ICON handle this?

Edit note: Why in some files the model level is called height and in others height_2 is due to the ordering of the height variables in the forcing data (sometimes model levels are listed first and sometimes second). Therefore the new question:

  • How can it be that the forcing data structure is different for different time steps?
2

As far as I know, you always have to post-process. I typically use ncrename to do the remapping.
How do you get these different input files? Running your CDO command for different fields? With different fields you might end up with different dimensions - and thus dimension names.

Depends on what the files contain and how you used them (see above question, I did not fully understand how you got these differences).

Yes!

Apart from that, you can also check out the capabilities of auto-icon, which can besides running your ICON run also do a bunch of remapping of input data/icbc data (see here for details). It basically has a remapping scripts with CDO or the ICON tools built in for this purpose.

3

The input files are the ICON-EU forcing data from DWD. They differ in time (using multiple data files), but they have exactly the same fields. I found out that the ordering of the height variables (in the forcing data) is different and that this - I guess - results in the different names of model levels (height vs height_2) in the remapped data.

I guess the question is, if ICON can handle that the model levels of some remapped files are called height and others height_2, e.g. QS(time,height,cell) vs QS(time,height_2,cell)? And if ICON can handle using cell and nv instead of ncell and vertices.

Maybe @drieger or @fprill can comment on this?

4

In the ICON output convention `height` and `height_2` have different meanings, as far as I understand. While `height` contains the indices of the half levels, i.e. cell interfaces, `height_2` contains the indices for the full levels, i.e. staggered / cell center heights. These are not the actual heights (which differ per cell due to the terrain-following coordinates) to simplify the I/O file structure.

5

that is true. But I still was wondering if ICON can handle the naming difference of initial data output of the model level, e.g. QS(time, height_2, ncells) vs QS(time, height, ncells), due to CDO remapping.

ICON threw me an error when using cell and nv. So this I had to rename to ncells and vertices. But having “height” as model-level output indice (which is called height_2 in ICON), ICON did not complain. So I guess it does not matter if the height-variable of some initial data variables differ.

6

This is actually only the case, if you have both types of levels in the same file. If you have only one type of levels in the output it will always be called ‘height’, no matter which type of levels it is (e.g. writing only temp and w in two different files will yield the same dimension names time, height and ncells but the height coordinates will be different between the two).

7

cell and ncells should both be accepted (preference for cell). For height, ICON accepts either lev or a number of height dimensions, height and height_<i> where i ranges from 2 to 9. It takes the length of the shortest dimension as the number of levels.

Edit: The ordering and naming of height variables depends on the order of variables in the files. This is a CDI feature, the library used both by CDO and ICON to handle NetCDF I/O. Dimensions are created on-demand based on the Z axis type. Both half-level and full-level heights are named “height” by default. If CDI already has a dimension of the same name, it appends _2, _3, etc., when creating the new one. So whether height is the full- or half-level height depends on the relative ordering of variables like T or VN relative to W or HHL in the variable list of the output file.

The cell and height dimensions are the only ones where the names are significant. Variables are interpreted by dimension position, not name (1st is cell, 2nd is height, etc.).