Hello. I am a GMT veteran of 25 years, not a newbie.
I have been able to replicate the following problem in GMT 6.0 fresh installs under linux and MacosX.
Say I use grdsample to extract a grid that is higher resolution subset of a larger grid like this:
$gmt grdsample stempmin.6.grd -Gstempmin.grd -R10/12.3/5/16 -I600+n/766+n
where my source grid in this example is a smooth1 degree global geographical grid of surface temperatures with valid floating point values at all nodes:
$ gmt grdinfo stempmin.6.grd
stempmin.6.grd: Title: z
stempmin.6.grd: Command: /home/robd/GMT41/GMT4.1/GMT4.1.3/bin/grdmath /home/robd/AVNGRD/tmp.grd 273.3 SUB = /home/robd/AVNGRD/stempmin.6.grd
stempmin.6.grd: Remark:
stempmin.6.grd: Gridline node registration used [Cartesian grid]
stempmin.6.grd: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7
stempmin.6.grd: x_min: 0.000 x_max: 360.000 x_inc: 1.000 name: n_columns: 361
stempmin.6.grd: y_min: -90.000 y_max: 90.000 y_inc: 1.000 name: n_rows: 181
stempmin.6.grd: z_min: -55.010 z_max: 36.470 name: z
stempmin.6.grd: scale_factor: 1.000 add_offset: 0.000
stempmin.6.grd: format: classic
The strange problem arises where the maximum longitude value in the small subregion has a fractional part that is less than or equal to 0.5
When that happens, it gives NaN values for all columns >12.0 degrees
$ gmt grd2xyz stempmin.grd | grep NaN | head -1
12.001 16.000 NaN
I can work around the bug by extracting a region where the domain of X has a maximum that has a larger fractional part but this is messy to implement across many scripts:
$ gmt grdsample stempmin.6.grd -Gstempmin.grd -R10/12.6/5/16 -I600+n/766+n
$ gmt grd2xyz stempmin.grd | grep NaN | wc -l
0
If I had been careful about the number of rows and columns I could cut that larger grid in the desired longitude range 10/12.3 to give me correct values at all nodes.
It does not make any difference whether the input/output are defined as global and it doesn’t matter what interpolation parameters I choose: it even gives NaNs using near-neighbor.
It does not matter if the input grid is changed to some other form.
It does not matter if define dx/dy intervals explicitly with -I instead
The bug is not shared with grdtrack, even though grdtrack presumably has much in common with grdsample:
$ echo “12.3 45” | gmt grdtrack -Gstempmin.6.grd
12.300 45.000 8.645
$ echo “12.6 45” | gmt grdtrack -Gstempmin.6.grd
12.600 45.000 10.473
This looks like it should be a trivial bug to fix.
Where I use GMT4.5 there is no problem in grdsample butI have a vague recollection of a similar problem in grdsample around about GMT3.2. Has some ancient buggy code returned?