Ocean and sea-ice data from the AWI Climate Model (AWI-CM) and AWI Earth System Model (AWI-ESM) for CMIP6 are generally provided on the native unstructured triangular grid in order to avoid a loss of information and/or inflation of file sizes. For many applications it will however be convenient to interpolate these data to a regular (curvilinear) grid because many analyses are tailored to the latter more common type of grid.

The description of the grid, which is required for remapping, is included in all data files: the variables “lon” and “lat” store the coordinates of the triangle vertices (nodes), and the variables “lon_bnds” and “lat_bnds” store the coordinates of the corresponding polygons around the nodes. These polygons are composed of the triangular edge medians and the triangular centroids, so that a bounding polygon for a typical non-coastal node with 6 neighbours is composed by 2 x 6 = 12 points. Given that FESOM grids are generally not orthogonal, some nodes have more than 6 neighbours. Thus the corresponding dimension of the arrays “lon_bnds” and “lat_bnds” is generally larger than 12 to account for nodes with more than 6 neighbours.

 A convenient way to remap FESOM data to a regular (curvilinear) grid is to use the Climate Data Operators (CDO: code.mpimet.mpg.de/projects/cdo/), in particular the CDO operator ‚remaycon‘ for first-order conservative remapping. If you have CDO installed (widely available at high-performance computing centres with climate research users), you can download an AWI-ESM CMIP6 example file (either 2D* or 3D*) using one of the links provided below, and try the following command to remap the data to a global 1-degree lon-lat grid:

> cdo remapycon,global_1 <inputpath>/<inputfilename> <outputpath>/<outputfilename>

CDO allows you to specify a wide range of target grids. Furthermore, instead of a predefined target grid, another file can be specified to remap onto the grid contained in that file. Details can be found in the CDO documentation (see link above).

If you intend to remap a large number of FESOM files, it is advisable to split the operation into the generation of remapping weights with “genycon” and the remapping itself with “remap”:

> cdo genycon,global_1 <inputpath>/<inputfilename> <outputpath>/<weightsfilename>
> cdo remap,global_1,<outputpath>/<weightsfilename> <inputpath>/<inputfilename> <outputpath>/<outputfilename>

Note that CDO assumes that the values provided at the nodes are valid across the corresponding polygons, that is, piecewise constant, which can be thought of as a finite-volume-interpretation of the discretized field. This is accurate for the new finite-volume version of FESOM (FESOM2), but not exactly correct for the finite-element-version of FESOM (FESOM1, which was used for CMIP6), where fields are rather defined such that values vary linearly between nodes. However, integrals remain correct, so any associated errors can be assumed to be small.

Please be careful when using remapped FESOM data to derive quantities such as mass or heat fluxes or overturning; these can be rather sensitive to the remapping. If in doubt, please contact the FESOM team!

• 2D* example file (ocean surface temperature, 28MB)
• 3D* example file (ocean potential temperature, 165MB)

If you encounter FESOM files that do not have the grid variables (lon, lat, lon_bnds, lat_bnds) included (which should not be the case for CMIP6 data though), a separate grid description file can be used in combination with the CDO operator “setgrid” to add the grid information. Grid description files in turn can be generated from native FESOM grid information with the R-package spheRlab, which is available on GitHub: github.com/FESOM/spheRlab . If you need help with this, please contact the FESOM team!

_{*) 2D or 3D here refers to a physical 2D or 3D field, that is, a field with two horizontal dimensions and, in case of 3D, an additional vertical dimension. Given that the input files provide these on an unstructured grid, the two horizontal dimensions are stored in just one (unstructured) dimension, so that 2D or 3D data are stored in 1D or 2D arrays. That’s not the case anymore for the remapped files, where 2D or 3D correspond to 2D or 3D arrays.}