Bug #1167
Suboptimal auto -R in modern mode and problems with automatic CPT after scaling grid
Status: | Closed | Start date: | 2017-11-01 | |
---|---|---|---|---|
Priority: | Normal | Due date: | ||
Assignee: | % 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
History
#1
Updated by Andreas over 3 years 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 over 3 years 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 over 3 years 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 over 3 years 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 over 3 years 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 over 3 years ago
Ubuntu bash for Windows 10, yes.
#7
Updated by Paul over 3 years ago
Just a note on usage: In modern mode, accessing modules via the gmt executable will be required.
#8
Updated by Andreas over 3 years 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 over 3 years 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 over 3 years 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 over 3 years ago
Darn, was afraid of user errors; stuff I dont usually use. Thanks Paul. Glad some info was of use.
#12
Updated by Paul about 3 years ago
- Status changed from Resolved to Closed
Closed as fixed, I think.