Bug #592

grdmath -R with file name erroneously passing grid params

Added by John almost 3 years ago. Updated over 2 years ago.

Status:ClosedStart date:2014-07-29
Priority:NormalDue date:
Assignee:Remko% Done:

100%

Category:-
Target version:Candidate for next bugfix release
Affected version:5.1.1 Platform:Mac OS X

Description

I have seen another odd bit of behavior. This time with grdmath, when passing the -R parameters as a file name.

Here is the sequence in words.

  1. Create a file of set value )zero, in this case) with specified -R0/359.75/-90/90 and -I0.25.
  2. run grdinfo to check the file just created.
  3. now create a new file of values set to one.
  4. run grdinfo to check that it is created properly.

Here is an example of my results.

gmt grdmath -R0/359.75/-90/90 -I0.25 0 = t0.grd
gmt grdinfo t0.grd

t0.grd: Title: Produced by grdmath
t0.grd: Command: grdmath -R0/359.75/-90/90 -I0.25 0 = t0.grd
t0.grd: Remark:
t0.grd: Gridline node registration used [Cartesian grid]
t0.grd: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
t0.grd: x_min: 0 x_max: 359.75 x_inc: 0.25 name: x nx: 1440
t0.grd: y_min: -90 y_max: 90 y_inc: 0.25 name: y ny: 721
t0.grd: z_min: 0 z_max: 0 name: z
t0.grd: scale_factor: 1 add_offset: 0
t0.grd: format: netCDF-4 chunk_size: 131,145 shuffle: off deflation_level: 0

gmt grdmath -Rt0.grd 1 = t1.grd
gmt grdinfo t1.grd

t1.grd: Title: Produced by grdmath
t1.grd: Command: grdmath -Rt0.grd 1 = t1.grd
t1.grd: Remark:
t1.grd: Gridline node registration used [Cartesian grid]
t1.grd: Grid file format: nf = GMT netCDF format (32-bit float), COARDS, CF-1.5
t1.grd: x_min: 0 x_max: 360 x_inc: 0.25 name: x nx: 1441
t1.grd: y_min: -90 y_max: 90 y_inc: 0.25 name: y ny: 721
t1.grd: z_min: 1 z_max: 1 name: z
t1.grd: scale_factor: 1 add_offset: 0
t1.grd: format: netCDF-4 chunk_size: 131,145 shuffle: off deflation_level: 0@

The longitude extent and the number of cells in the x-direction has changed from t0.grd to t1.grd.

Shouldn't they be the same?

This is with macports, GMT Version 5.1.1 (r12968) [64-bit]. MacOS X 10.7.5.

Please update macports when this bug has been corrected. Thanks!

Associated revisions

Revision 13563
Added by Remko over 2 years ago

Merge from trunk.
Fixed issue #592

History

#1 Updated by Paul almost 3 years ago

  • Status changed from New to In Progress
  • Target version set to Candidate for next bugfix release

Hm, looks like some auto-cleverness for geographic grids going wrong. Will have a look.

#2 Updated by Paul almost 3 years ago

  • Assignee set to Remko

Passing the buck to Remko as I will be gone for some days. Remko, apologies if you are on vacation!

#3 Updated by Remko almost 3 years ago

I reproduced this bug in 5.2.0 r13400.
It must be related to the way we automatically decide whether a grid is global and do an automatic padding to aid interpolation across the Greenwich meridian.
The equivalent happens with -R-180/179.75/-80/80.

#4 Updated by Paul almost 3 years ago

That is what I thought, too, hence I passed it to you!

#5 Updated by Remko over 2 years ago

Stopped -Rgrid from changing the longitude boundaries automatically to global when only, for example, 0/359.
This should fix this issue, hopefully without side effects.
Fixes were made in r13560 (for GMT 5.1.x) and r13563 (for GMT 5.2.x)

#6 Updated by Remko over 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

#7 Updated by Paul over 2 years ago

  • Status changed from Resolved to Closed

Closing this one as fixed.

Also available in: Atom PDF