30
BAMOS
Mar 2019
Research corner
with Damien Irving
Data analysis and ocean model grids
Since making the shift from an atmosphere-based PhD to
an ocean-based postdoc, I’ve spent more time than I’d like
getting my head around ocean model grids. In particular, the
convention for modelling groups participating in CMIP5 was
to archive ocean variables on the native model grid. Some of
the CMIP5 ocean models run on a rectilinear grid (i.e. a regular
latitude/longitude grid like the atmosphere model), but most
are run on some sort of curvilinear grid (i.e. a grid where the
coordinate lines are curved). The details of these curvilinear
grids are in most cases not widely available, but the (netCDF)
data files do contain auxiliary coordinate information that
specifies the location of each curvilinear grid point in latitude-
longitude space.
At some point, most analysis of CMIP5 ocean data involves
remapping from the native curvilinear grid to a regular latitude/
longitude grid. I’ve found that the level of complexity involved
in this remapping depends on whether you’re dealing with a
scalar or vector quantity, and whether there are conservation
properties that need to be maintained (e.g. conservation of
energy or moisture).
The discussion that follows is my attempt to step through
each level of complexity, exploring the software packages
and analysis approaches currently used for remapping from a
curvilinear to rectilinear grid.
1. Scalar quantity
The most simple case involves remapping a scalar quantity such
as temperature or salinity from a curvilinear to rectilinear grid.
There are a number of libraries out there for doing this, such as:
• Python (iris): regrid_weighted_curvilinear_to_rectilinear
• Python (xarray): xESMF
• NCL: rcm2grid
• NCO: ncremap
2. Scalar quantity with conservation
The next level of complexity involves remapping a scalar
quantity such as ocean heat content (OHC), where it can be
important to conserve the grid sum/total. The remapping
packages listed above approximately conserve the grid mean,
but unfortunately not the grid sum if there are missing values
(i.e. due to the presence of land). This is because some ocean
area/volume is gained or lost as the continents subtly change
shape between the old and new grid. One of the reasons why
CMIP5 ocean data is archived on the native model grid is that
providing remapped data would make it impossible to close
energy budgets.
To work around this problem, people tend to devise their
own scheme for moving from curvilinear to rectilinear space.
This typically involves making use of the auxiliary coordinate
information contained in the CMIP5 data files. For instance, in
calculating the zonally integrated OHC (while conserving the
global total), Nummelin et al. (2017) essentially iterate over
each one degree latitude band, adding up the OHC from all
grid cells whose auxiliary coordinate falls within that band.
Another (potentially simpler) option can be to replace the land
mask / missing values with zeros. In this case the grid sum will
be conserved after remapping with the packages listed above,
with the caveat that the new values along the coastline should
be interpreted as a scaled/reduced value according to land/sea
fraction.
3. Vector quantity
The most complex case is when remapping vector quantities
such as heat flux (hf ) or water velocity. The x and y components
of such variables are archived as two separate variables (e.g. hfx
and hfy). The complexity arises because the x and y directions
on a curvilinear grid are not everywhere the same as the x
(eastward) and y (northward) directions on a geographic
latitude/longitude grid. This means you can’t apply the
aforementioned software packages or work-arounds to move
from curvilinear to rectilinear space—any remapping requires
the use of information from both the native x and y components.
The most obvious solution to this problem would be to convert
the native x and y components into eastward and northward
components using the grid angle at each grid cell. Unfortunately,
the CMIP5 modelling groups didn’t archive a grid angle variable,
and even if they did it turns out that complications can arise.
Using grid angles obtained for the NorESM1-M model, Outten
et al. (2018) calculated the northward heat transport from the
native hfx and hfy components and found small differences
compared to the northward heat transport output directly from
the model (the hfbasin variable). Investigation revealed that the
grid angle was given for the p points of the grid cells (i.e. the
center of each grid cell), while the hfy and hfx were given on
the top and bottom and left and right edges of the grid cell,
respectively, as per a standard C-grid configuration. Thus the
angles given were not precisely accurate for the locations of
hfy and hfx. It’s possible that these issues might be overcome
using the xgcm package (which interpolates variables from one
position to another on a C-grid), but the use of that package