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?
 This is mostly to organize things on our side, not something you need to worry about.
 This is mostly to organize things on our side, not something you need to worry about.