Surface crashes in 6.4.0 but not in 5.4.2

[mkbarker]

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

[mkbarker]

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]

[Joaquim]

@mkbarker

l-11u11

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

[mkbarker]

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.

[Joaquim]

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

[mkbarker]

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

[pwessel]

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

[Joaquim]

@mkbarker

surface -r -bi3 -R-19/-3/-20/-4 -I0.005 -T0.75 -Gtmp.grd -C0.001 -Ll-11u11

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.

[Joaquim]

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)

[pwessel]

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.

[pwessel]

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.

[mkbarker]

Hello! Just wondering if there’d been any progress on this? Let me know if any other info/data are needed from me.

[pwessel]

Sorry, no, and now AGU is upon us… We need to make a clean bug report issue on GitHub for this case first.

[mkbarker]

Is that something I should do? Sorry for the dumb question… I’m not sure what the normal procedure is.

[pwessel]

Well, if you have time you could. We need a bug report issue to be opened on GitHub that demonstrates the problem. That would in essence copy much info from this page and append the needed data to reproduce the problem in master that seems related to -r. We can then track efforts on GitHub (forum is not great for that).

[mkbarker]

OK, I submitted a bug report:

Surface crashes in 6.4.0

[pwessel]

Thanks!

[mkbarker]

And, FWIW, I do not encounter this bug in v6.3.0…

[pwessel]

Good information, may make it easier to compare and contrast for me.

[pwessel]

Bug should be fixed now in the master repo Please give it a spin.