Bug #1167

Suboptimal auto -R in modern mode and problems with automatic CPT after scaling grid

Added by Andreas 17 days ago. Updated 7 days ago.

Status:ResolvedStart date:2017-11-01
Priority:NormalDue date:
Assignee:Paul% Done:

100%

Category:-
Target version:Candidate for next minor release
Affected version:6.x-svn Platform:

Description

1. Auto -R in modern mode is a bit sloppy. Compare with auto -R in classic mode.

Good auto R - classic mode
grdimage bat_200.nc -P -Bafg -Jx1:200000 --PS_MEDIA=A0 -I > good_auto_R_classic_mode.ps && psconvert -Tf -A -Z good_auto_R_classic_mode.ps

Non-optimal auto R - modern mode
gmt begin non_optimal_R_modern_mode && grdimage bat_200.nc -P -Bafg -Jx1:200000 --PS_MEDIA=A0 -I && gmt end

2. I want to scale a grid (multiply by -1, +s-1) and then plot it with an automatic CPT - fails:

Modern mode:
$ gmt begin test && grdimage bat_200.nc=+s-1 -P -Bafg -Jx1:200000 --PS_MEDIA=A0 -I && gmt end
grdimage [ERROR]: Passing max ⇐ zmin prevents automatic CPT generation!
psconvert [ERROR]: Unable to decode BoundingBox file ./psconvert_56c.bb
psconvert [ERROR]: Failed to remove ./psconvert_56c.bb! [remove error: No such file or directory]
ERROR: Caught signal number 11 (Segmentation fault) at
/lib/x86_64-linux-gnu/libc.so.6(fclose+0x4)[0x7f3ab3a4d264]
[0x0]
Stack backtrace:
/usr/local/lib/libgmt.so.6(sig_handler+0x2b1)[0x7f3ab4004aa1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7f3ab3dc1390]
/lib/x86_64-linux-gnu/libc.so.6(fclose+0x4)[0x7f3ab3a4d264]
/usr/local/lib/libgmt.so.6(GMT_psconvert+0x44d2)[0x7f3ab42663b2]
/usr/local/lib/libgmt.so.6(GMT_Call_Module+0x135)[0x7f3ab4019cb5]
/usr/local/lib/libgmt.so.6(+0x1469d5)[0x7f3ab41169d5]
/usr/local/lib/libgmt.so.6(gmt_manage_workflow+0x154)[0x7f3ab4117514]
/usr/local/lib/libgmt.so.6(GMT_end+0x30b)[0x7f3ab40058bb]
/usr/local/lib/libgmt.so.6(GMT_Call_Module+0x135)[0x7f3ab4019cb5]
gmt(main+0x987)[0x4015d7]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f3ab3a00830]
gmt(_start+0x29)[0x401689]

Classic mode:
$ grdimage bat_200.nc=+s-1 -P -Bafg -Jx1:200000 --PS_MEDIA=A0 -I
grdimage [ERROR]: Passing max ⇐ zmin prevents automatic CPT generation!

Using 6.0.0_r19216

bat_200.nc (571 KB) Andreas, 2017-11-01 04:23

good_auto_R_classic_mode.pdf (548 KB) Andreas, 2017-11-01 04:23

non_optimal_R_modern_mode.pdf (549 KB) Andreas, 2017-11-01 04:23

Associated revisions

Revision 19237
Added by Paul 16 days ago

Address issue #1167

History

#1 Updated by Andreas 17 days ago

Another thing regarding modern vs. classic mode.

I want to create a plot with classic mode, so I type:

$ grdimage bat_200.nc -P -Bafg -Jx1:200000 --PS_MEDIA=A0 -I > good_auto_R_classic_mode.ps
$ psconvert -Tf -A -Z good_auto_R_classic_mode.ps
psconvert [ERROR]: The -Z option is not available in MODERN mode!
psconvert [ERROR]: Syntax error: No listed input files allowed under modern GMT mode
psconvert [ERROR]: Syntax error: Modern GMT mode requires the -F option

but GMT complains about stuff as I was working with modern mode. Why? I have not invoked gmt begin/end that should trigger modern stuff.

#2 Updated by Paul 17 days ago

Your modern session crashed so you may need to remove the tmp dir with the previous GMT session?
Suspect you are on Windows where the OS cannot give us a stable parent process ID so we use 0. You may have to remove /tmp/gmt6.0.

#3 Updated by Paul 16 days ago

  • Status changed from New to Resolved
  • Assignee set to Paul
  • Target version set to Candidate for next minor release
  • % Done changed from 0 to 100

The auto-region default has to be exact, otherwise people will get angry. So I changed that. I then fixed a bug in the scaling that failed to flip min/max z after the negative scaling. In r19237.

#4 Updated by Andreas 16 days ago

Great Paul.

I'm actually on Windows 10 - using bash for windows. This is the content of my /tmp:

$ dir /tmp
gmt6.10630  gmt6.132  gmt6.2    gmt6.2282  gmt6.2807  gmt6.39    gmt6.4097  gmt6.457  gmt6.9747  gmt6.9993
gmt6.12275  gmt6.135  gmt6.212  gmt6.254   gmt6.36    gmt6.4078  gmt6.43    gmt6.72   gmt6.9911

I was playing around with modern mode and made some failed attempts (obviously).

#5 Updated by Paul 16 days ago

OK, so Ubuntu bash for Windows 10 then? I have that too for testing. So clearly we are setting the PPID in that environment but I am not sure if it is stable or correct since at some point it must be getting this information from Windows.

#6 Updated by Andreas 15 days ago

Ubuntu bash for Windows 10, yes.

#7 Updated by Paul 15 days ago

Just a note on usage: In modern mode, accessing modules via the gmt executable will be required.

#8 Updated by Andreas 8 days ago

Noted - thanks Paul.

Also encountered this problem when dealing with 'GDAL driver'-grids and e.g. scaling (+s);

$ grdmath -R0/1000/0/1000 -I1 5 2 RAND = rand.tif=gd:GTIFF

$ grdmath rand.tif=+s0.1 100 MUL = test.nc
grdmath (api_import_grid): NetCDF: Unknown file format [rand.tif=+s0.1]
[Session grdmath (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdmath (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdmath (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
ERROR: Caught signal number 11 (Segmentation fault) at
/usr/local/lib/libgmt.so.6(gmtgrdio_free_grid_ptr+0x70)[0x7fb026c59cf0]
[0x10]
Stack backtrace:
/usr/local/lib/libgmt.so.6(sig_handler+0x2b1)[0x7fb026c050d1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7fb0269c1390]
/usr/local/lib/libgmt.so.6(gmtgrdio_free_grid_ptr+0x70)[0x7fb026c59cf0]
/usr/local/lib/libgmt.so.6(+0x3fb48)[0x7fb026c0fb48]
/usr/local/lib/libgmt.so.6(gmtapi_garbage_collection+0x1ee)[0x7fb026c119be]
/usr/local/lib/libgmt.so.6(gmt_end_module+0x186)[0x7fb026d121b6]
/usr/local/lib/libgmt.so.6(GMT_grdmath+0x754)[0x7fb026e34374]
/usr/local/lib/libgmt.so.6(GMT_Call_Module+0x135)[0x7fb026c1c325]
grdmath(main+0x8c6)[0x401516]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fb026600830]
grdmath(_start+0x29)[0x4016c9]

$ grdimage rand.tif=+s0.1 -P -JX10c -Bafg > rand_plot.ps
grdimage (api_import_grid): NetCDF: Unknown file format [rand.tif=+s0.1]
[Session grdimage (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdimage (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
[Session grdimage (0)]: Error returned from GMT API: GMT_GRID_READ_ERROR (18)
ERROR: Caught signal number 11 (Segmentation fault) at
/usr/local/lib/libgmt.so.6(gmtgrdio_free_grid_ptr+0x70)[0x7feffb459cf0]
[0x10]
Stack backtrace:
/usr/local/lib/libgmt.so.6(sig_handler+0x2b1)[0x7feffb4050d1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11390)[0x7feffb1c1390]
/usr/local/lib/libgmt.so.6(gmtgrdio_free_grid_ptr+0x70)[0x7feffb459cf0]
/usr/local/lib/libgmt.so.6(+0x3fb48)[0x7feffb40fb48]
/usr/local/lib/libgmt.so.6(gmtapi_garbage_collection+0x1ee)[0x7feffb4119be]
/usr/local/lib/libgmt.so.6(gmt_end_module+0x186)[0x7feffb5121b6]
/usr/local/lib/libgmt.so.6(GMT_grdimage+0xdcb)[0x7feffb69bc4b]
/usr/local/lib/libgmt.so.6(GMT_Call_Module+0x135)[0x7feffb41c325]
grdimage(main+0x8c6)[0x401516]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7feffae00830]
grdimage(_start+0x29)[0x4016c9]

Tested with gd:GTIFF and gd:ZMAP - same result.

#9 Updated by Paul 8 days ago

Sorry, user error: You are not giving any grid type after your = sign. Should be

grdmath rand.tif=gd+s0.1 100 MUL = test.nc

which works fine. I note

grdmath rand.tif 100 MUL = test.nc

works while
grdmath rand.tif+s0.1 100 MUL = test.nc

fails. Looking at that now.

#10 Updated by Paul 7 days ago

Removed the requirement that =type must always precede grid sale/offset modifiers. So rand.tif+s0.1 etc now works. r19315.

#11 Updated by Andreas 7 days ago

Darn, was afraid of user errors; stuff I dont usually use. Thanks Paul. Glad some info was of use.

Also available in: Atom PDF