Surface crashes in 6.4.0 but not in 5.4.2

Hello,

GMT 6.4.0 surface routine crashes with this:

gmt blockmedian Site01_scatInterp_v1_final_adj.xyzi -bi4 -R-19/-3/-20/-4 -I0.005 -C -bo3 -r | gmt surface -r -bi3 -R-19/-3/-20/-4 -I0.005 -T0.75 -Gtmp.grd -C0.001 -Ll-11u11

but it works if I leave out the “-Ll-11u11” flag.

This works in 5.4.2 with the “-Ll-11u11” flag.

Link to input file.

Any help would be much appreciated.

Thank you,
Mike

FWIW, here is the error output.

ERROR: Caught signal number 11 (Segmentation fault) at

/panfs/ccds02/nobackup/people/sberton2/.spack_repo/opt/spack/linux-centos7-haswell/gcc-11.1.0/gmt-6.4.0-xdmacvrgjo3w4eprh25qlo4fjsxfjx5u/lib64/libgmt.so.6(+0x381d48)[0x2ba2a5d56d48]

[0x2ba2b336c000]

Stack backtrace:

/panfs/ccds02/nobackup/people/sberton2/.spack_repo/opt/spack/linux-centos7-haswell/gcc-11.1.0/gmt-6.4.0-xdmacvrgjo3w4eprh25qlo4fjsxfjx5u/lib64/libgmt.so.6(sig_handler_unix+0xc5)[0x2ba2a5b04f55]

/lib64/libpthread.so.0(+0xf630)[0x2ba2a91f6630]

/panfs/ccds02/nobackup/people/sberton2/.spack_repo/opt/spack/linux-centos7-haswell/gcc-11.1.0/gmt-6.4.0-xdmacvrgjo3w4eprh25qlo4fjsxfjx5u/lib64/libgmt.so.6(+0x381d48)[0x2ba2a5d56d48]

/panfs/ccds02/nobackup/people/sberton2/.spack_repo/opt/spack/linux-centos7-haswell/gcc-11.1.0/gmt-6.4.0-xdmacvrgjo3w4eprh25qlo4fjsxfjx5u/lib64/libgmt.so.6(+0x3828c7)[0x2ba2a5d578c7]

/panfs/ccds02/nobackup/people/sberton2/.spack_repo/opt/spack/linux-centos7-haswell/gcc-11.1.0/gmt-6.4.0-xdmacvrgjo3w4eprh25qlo4fjsxfjx5u/lib64/libgmt.so.6(GMT_surface+0x31b4)[0x2ba2a5d5b354]

/panfs/ccds02/nobackup/people/sberton2/.spack_repo/opt/spack/linux-centos7-haswell/gcc-11.1.0/gmt-6.4.0-xdmacvrgjo3w4eprh25qlo4fjsxfjx5u/lib64/libgmt.so.6(GMT_Call_Module+0x33e)[0x2ba2a5a2a2de]

gmt(main+0x412)[0x404ea2]

/lib64/libc.so.6(__libc_start_main+0xf5)[0x2ba2a9d8c555]

gmt[0x405bb3]

What is the 11 after the u intended to mean? I can’t find a frame for it in the manual.

Upper limit in data units (km in this case)

-Ll|u
Constrain the range of output values; append directive and value, repeatable:
l: Set lower limit; forces solution to be >= .
u: Set upper limit; forces solution to be <= .
Note: can be any number, or the letter d for min (or max) input data value, or the filename of a grid with bounding values [Default solution is unconstrained]. Example: -Ll0
enforces a non-negative solution.

Except that by repeatable it is meant: “You can use -Ll-11 and -Lu11” and not -Ll-11u11

It still crashes if using “-Ll-11 -Lu11”.

From memory I think I fixed something related to surface since 6.4.0. Are you able to try your command using git master?

It still crashes if I use any of those -L

gmt blockmedian Site01_scatInterp_v1_final_adj.xyzi -bi4 -R-19/-3/-20/-4 -I0.005 -C -bo3 -r | gmt surface -r -bi3 -R-19/-3/-20/-4 -I0.005 -T0.75 -Gtmp.grd -C0.001

but look at the grid’s min/max.

grdinfo tmp.grd
tmp.grd: Title: Data gridded with continuous surface splines in tension
tmp.grd: Command: gmt surface -r -bi3 -R-19/-3/-20/-4 -I0.005 -T0.75 -Gtmp.grd -C0.001
tmp.grd: Remark:
tmp.grd: Pixel node registration used [Cartesian grid]
tmp.grd: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7
tmp.grd: x_min: -19 x_max: -3 x_inc: 0.005 name: x n_columns: 3200
tmp.grd: y_min: -20 y_max: -4 y_inc: 0.005 name: y n_rows: 3200
tmp.grd: v_min: -4.04500627518 v_max: 1.9595233202 name: z

and the grid itself seems to suffer from some transposition problem.

Paul, why would the -r in the surface command result in the grid above? Smells bug too. Look without that -r.

gmt blockmedian Site01_scatInterp_v1_final_adj.xyzi -bi4 -R-19/-3/-20/-4 -I0.005 -C -r | gmt surface -R-19/-3/-20/-4 -I0.005 -T0.75 -Gtmp.grd -C0.001

We can clearly see the Moon

julia> imshow("tmp.grd", shade=true, figsize=8)

Yes, looks fishy. But we have a test/surface using -r so cannot tell - also at conference so not able to work on this now.

Odd. Chaining to -I0.0025 (twice the resolution) yields the same diagonal line but from LL to UR, while going to -I0.01 (half the resolution) yields a correct plot.