Esmvaltool: Default linear regridder and nearest regridder extrapolation mode

Created on 31 May 2017  路  7Comments  路  Source: ESMValGroup/ESMValTool

At the moment, the backend regrid function supports the 'linear' and 'nearest' schemes in order to perform bilinear interpolation regridding and nearest neighbour regridding.

For both of these schemes, the regridder uses the default extrapolation_mode - see the associated docs iris.analysis.Linear and iris.analysis.Nearest for further details.

In both cases, the default extrapolation_mode may not be appropriate, given the users expectation and their data e.g. @valeriupredoi used the linear regridder on a limited domain dataset of air_temperature in units of K over North America i.e. iris.sample_data_path('E1_north_america.nc'), and regridded to a 30x30 global target grid ... needless to say, the resultant regridded cube contained extrapolated data points below 0K. Bummer.

The simple fix (on my advice) was for him to change the default linear regridder to be Linear(extrapolation_mode="mask") in his branch. This indeed, resolved the issue.

So that all said,

  • do we want to change the default extrapolation_mode for both linear and nearest schemes? And if so, to what? I propose mask.
  • do we want users to be able to specify the extrapolation_mode in their namelist? And if so, the parser, the orchestrator (or what ever it's called these days) and the API to the backend regrid function need to change to support this.

Thoughts?

question

All 7 comments

Oh, and I just created a backend label, for issues that are specific to the backend ... thought that it might help separate backend issues from all other ESMValTool issues. Delete if you consider it inappropriate :smile:

  • do we want to change the default extrapolation_mode for both linear and nearest schemes? And if so, to what?

My answer would be yes. This is probably the safest option for the users.

  • do we want to users to be able to specify the extrapolation_mode in their namelist? And if so, the parser, the orchestrator (or what ever it's called these days) and the API to the backend regrid function need to change to support this.

I see no reason to not expose this option to the users

My answer would be yes. This is probably the safest option for the users.

@jvegasbsc I'm assuming that you'd agree with a default of extrapolation_mode="mask" for both 'linear' and 'nearest' ...

@jvegasbsc I'm assuming that you'd agree with a default of extrapolation_mode="mask" for both 'linear' and 'nearest' ...

Yes, it will be very error prone to set different defaults for different methods

Ping @mattiarighi

Sorry for the late reply.
I agree with @jvegasbsc, there is no point in exposing the user to unnecessary settings.
We want to keep the yaml namelist simple and readable for the user.
Setting extrapolation_mode="mask" is the safest solution.

Corresponding branch has been merged. ;-)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jvegasbsc picture jvegasbsc  路  4Comments

axel-lauer picture axel-lauer  路  5Comments

jonnyhtw picture jonnyhtw  路  4Comments

nielsdrost picture nielsdrost  路  3Comments

valeriupredoi picture valeriupredoi  路  4Comments