regridding to a NEMO grid

[Niall Robinson]

Hello,

I've got some data on a standard HadCM regular grid and want to regrid it onto a whacky NEMO grid like this one
http://www.nemo-ocean.eu/About-NEMO/Gallery/Meshmask-grid

Does anyone know if Iris can do this? I have a template nemo cube, with 2D lat and lon coords, but the basic regrid doesn't seem to work as I got

Cube u'sea_water_x_velocity' must contain a single 1D x coordinate

Thanks in advance

Niall

[Niall Robinson]

p.s. If iris can do this before the other guy in my group does it with IDL etc then it will win Iris some kudos in my group

[Richard Hattersley]

This might be possible via the experimental, and hence snappily titled, iris.experimental.regrid_conservative.regrid_conservative_via_esmpy().

NB. EMSPy is still in development so it's interface has changed a few times. Hence you need to install just the right version for this Iris function to work. If it's of interest I'll try to get someone to dig out an exact version number.

Out of interest, we're working on a quick but approximate regridding scheme for converting from high-res, "whacky" ocean grids to low-res, regular atmosphere grids. With a bit of luck it'll land on master in the next few days.

[Niall Robinson]

Hi Richard,

Thanks for the tip off, however it still doesn't seem to work. Don't know if this is due to the version of the software I'm using (latest iris dev and then whatever is installed at the met office). Here is my nemo template cube.

sea_water_x_velocity / (m/s)        (*ANONYMOUS*: 1021; *ANONYMOUS*: 1442)
     Auxiliary coordinates:
          latitude                              x                  x
          longitude                             x                  x
     Scalar coordinates:
          depth: 0.50576 m, bound=(0.0, 1.02391) m
          time: 2000-12-16 00:00:00, bound=(2000-12-11 00:00:00, 2000-12-21 00:00:00)
     Attributes:
          Conventions: CF-1.1
          TimeStamp: 19/11/2013 01:41:23 +0000
          file_name: /data/cr/cp/nrobin/nacvl/nacvlo_1m_20001201_20001230_grid_U.nc
          history: 2013-11-19T22:41:22: packnc -k 3 -d 1 -O nacvlo_1m_20001201_20001230_grid_U.nc...
          interval_operation: 1350.0
          interval_write: 864000.0
          online_operation: ave(only(x))
          production: An IPSL model

I also see that the docs say that the cubes cords need a coord_system but they have none

Have you got any other ideas? Should a nemo cube normally have a coord_system associated with it? Am I using the wrong software version?

Thanks
NIall

[Richard Hattersley]

Sorry, my mistake! That esmpy routine I pointed you at won't work with your data because it requires a rectilinear grid, but the NEMO grid is curvilinear. (The underlying ESMF library can deal with curvilinear grids which is what confused me.)

If you set the coord_system for the latitude and longitude coordinates on your NEMO Cube then you should be able to use iris.analysis.interpolate.regrid to do a simple linear interpolation.

[Niall Robinson]

Thanks Richard,

Is this something that should be recognised when the NEMO cube is loaded? The literature I can find on NEMO just calls it an "orthogonal curvilinear coordinate system" - do you know which of the
http://scitools.org.uk/iris/docs/latest/iris/iris/coord_systems.html?highlight=coord_system#iris.coord_systems
coord_systems it should correspond to?

Niall

[Richard Hattersley]

The lack of coordinate system stems from the lack of ellipsoid definition in the NEMO file. In effect, Iris knows there are latitude and longitude values for each grid cell, but it doesn't know exactly what "kind" of latitude and longitude they are. (Different ellipsoids assign the same physical location different lat/lon values.)

I suspect in this case the very minor ambiguities don't really matter. We're dealing with global scale data so the resolution of the grid is considerably larger than the shift in lat/lon values arising from different ellipsoids. But I'm wary of adding (more) arbitrary assumptions to Iris about data interpretation. Such assumptions could eventually cause hard to identify problems with detailed, local data.

In short, this is a tricky issue which needs some more careful thought!

(On a related note, if Iris is going to be "strict" about converting between coordinate systems then arguably it should only do so when both coordinate systems have a well-defined relationship to each other or a third reference system. Practically, this means both should have a relationship to WGS84, which is more than is captured in the current GeogCS class.)