Regional regridding

[bouweandela]

The current regrid preprocessor function only allows global grids, e.g. "1x1" degrees. It would be nice to have a more flexible preprocessor function that allows you to define a regional grid.

Maybe regrid_region with arguments latitude and longitude, which take 3 numbers as input, start, stop and step (or number of steps)?

Alternatively, we could combine the regrid and extract_region functions, so we first create the grid with the "1x1" syntax and then feed that to extract_region preprocessor before regridding? This could be implemented by just supplying the arguments of extract_region to regrid.

Opinions anyone? @mattiarighi @zklaus ?

[zklaus]

Just to be clear, the regridding, both regular and irregular works perfectly fine with regional grids (bugs notwithstanding), it's the construction of the target grid from a compact grid specification string that needs to be improved.

[zklaus]

In terms of regional model data, like from CORDEX, this is likely less of an issue since you can simply regrid to the existing regional grid.

[valeriupredoi]

if you want to combine multiple regions with different grids into a multimodel bin you will be in massive pain 😁 Why not combine extract_region followed by a per-region Mr x Nr regrid?

[bouweandela]

@Peter9192 @SarahAlidoost @nielsdrost It would be good to have your opinion on this. Specifically, would we need to be able to specify completely free grids, i.e. start/stop/stepsize or start/stop/numsteps? Or do we prefer to have grids that are a subset of a global grid? i.e. specify step size or number of steps on the global grid and then cut out a region? If you intend to later combine the regions again or compare to a global dataset, you would need the latter, but that gives less freedom.

Another issue is that specifying the step size tends look more user friendly at first glance, but may actually be more difficult to work with for users, because the start + the number of steps * step size must equal the end point. Due to rounding issues with floating point numbers it can be tricky to make this work as expected for users, because the number of steps must be an integer. See also #746.

[Peter9192]

I think flexibility in terms of the start and end points would be very nice, I can imagine we would use this for our hydrological model forcing data. Perhaps we could make the default a subset of the global grid, unless otherwise defined?

i.e. start/stop/stepsize or start/stop/numsteps

Yet another option would be start/stepsize/numsteps. That seems relatively user-friendly as well, and won't lead to any problems in inferring 'stop'. That could look something like

regrid:
  dx: 2.5 
  dy: 2.5
  x_origin: 0.0
  y_origin: 0.0
  nx: 144
  ny: 72

with a default setting for origin and nx/ny that represent a global grid? In this case, it would be convenient to have an additional keyword like approximate=False that would allow you to specify an approximate domain which is then shifted internally onto a subset of the global grid.

Note: whatever we choose, we should be very clear on what the origin or start/stop coordinates represent. Are they grid cell centers or corners?

[nielsdrost]

It would be nice to re-use some existing convention for this. The closest thing to a convention I could find is the cdo grid specification: https://code.mpimet.mpg.de/projects/cdo/embedded/index.html#x1-150001.3.2

It supports a lot of different options, but in its simplest versions seem to match what we also came up with. From the documentation:

CDO grid description example of a global regular grid with 60x30 points:

    gridtype = lonlat 
    xsize    =   60 
    ysize    =   30 
    xfirst   = -177 
    xinc     =    6 
    yfirst   =  -87 
    yinc     =    6

[SarahAlidoost]

I like Niels’ suggestion. Regarding rounding issues with floating-point numbers for step size (or y/xinc or pixel size), please see my comment on the issue #746.

[stefsmeets]

It would be nice to re-use some existing convention for this. The closest thing to a convention I could find is the cdo grid specification: https://code.mpimet.mpg.de/projects/cdo/embedded/index.html#x1-150001.3.2

It supports a lot of different options, but in its simplest versions seem to match what we also came up with. From the documentation:

CDO grid description example of a global regular grid with 60x30 points:

    gridtype = lonlat 
    xsize    =   60 
    ysize    =   30 
    xfirst   = -177 
    xinc     =    6 
    yfirst   =  -87 
    yinc     =    6

Hi @nielsdrost , we tried this approach in #1034 , but when @Peter9192 and I tested it, this convention felt awkward to use. Specifically because it is easy to mix up x/y when thinking about lon/lat, and having to do conversions to get xsize/ysize. I went with the start/stop/step named after lat/lon in the PR.

[Peter9192]

To expand on this a little: I think it would be nice to be consistent with the extract area preprocessor, which already has a partial grid spec like this:

      start_longitude: 0.0
      end_longitude: 39.0
      start_latitude: 30.0
      end_latitude: 76.25

Combine this with a latitude_step and longitude_step and you have a full grid spec.