Surface does not generate an output file

Added by David over 2 years ago

Dear GMT users,
Probably this is just something stupid but I haven't been able to figure out what I am doing wrong for more than a day now, so I hope you can help.

I am trying to convert grided binary input data (4-byte float little endian) like the attached file to a GMT grid file. Subsequently, the data should be interpolated to a higher resolution. Ultimately, grdcut should be used to cut the resulting file to the same extent as another grid file, so that I can apply grdmath.

Currently, my approach looks like this:

gmt xyz2grd 20171009.ztd -ZTLf -r -R74.2414160/74.917246630000000/42.342141060000000/42.9404720 -I0.000833330000000/.000833330000000 -G20171009-raw.grd -V
gmt surface 20171009-raw.grd?x/y/z -R74.2414160/74.917246630000000/42.342141060000000/42.9404720 -Q -I0.00001/0.00001 -G20171009.grd -Vl

The xyz2grd works nicely, the resulting grid looks just as expected.
Verbose output from the surface command also seems to be ok:

gmt: Your distance unit (e) implies geographic data; -fg has been set.
gmt: Map distance calculation will be using great circle approximation with authalic auxiliary latitudes and mean (R_1) radius = 0.0000 m, in meter.
gmt: Initialize FFTW with 16 threads.
surface: Grid is Cartesian
surface: Given domain implies x_inc = 1e-05
surface: Given domain implies y_inc = 1e-05
surface: Chosen boundary condition for all edges: natural
surface: Grid is Cartesian
surface: Grid domain: W: 74.241416 E: 74.91724663 S: 42.34214106 N: 42.940472 n_columns: 67583 n_rows: 59833 [gridline registration]
surface: Warning: Your grid dimensions are mutually prime.  Convergence is very unlikely.
surface: Hint: Choosing -R74.2337359928/74.9249366372/42.3413110587/42.9413120013 [n_columns = 69120, n_rows = 60000] might cut run time by a factor of 24697.268
surface: Hint: Choosing -R74.2337359928/74.9249366372/42.3341110474/42.9485120126 [n_columns = 69120, n_rows = 61440] might cut run time by a factor of 24131.897
surface: Hint: Choosing -R74.2337359928/74.9249366372/42.3302710414/42.9523520187 [n_columns = 69120, n_rows = 62208] might cut run time by a factor of 23833.906
surface: Hint: Choosing -R74.2193359794/74.9393366506/42.3413110587/42.9413120013 [n_columns = 72000, n_rows = 60000] might cut run time by a factor of 23714.731
surface: Hint: Choosing -R74.2294159888/74.9292566412/42.3413110587/42.9413120013 [n_columns = 69984, n_rows = 60000] might cut run time by a factor of 23700.109
surface: Hint: Choosing -R74.2294159888/74.9292566412/42.3302710414/42.9523520187 [n_columns = 69984, n_rows = 62208] might cut run time by a factor of 23533.652
surface: Hint: Choosing -R74.2337359928/74.9249366372/42.3213110273/42.9613120327 [n_columns = 69120, n_rows = 64000] might cut run time by a factor of 23166.539
surface: Hint: Choosing -R74.2193359794/74.9393366506/42.3341110474/42.9485120126 [n_columns = 72000, n_rows = 61440] might cut run time by a factor of 23164.06
surface: Hint: Choosing -R74.2294159888/74.9292566412/42.3341110474/42.9485120126 [n_columns = 69984, n_rows = 61440] might cut run time by a factor of 23144.637
surface: Hint: Choosing -R74.2148359752/74.9438366548/42.3413110587/42.9413120013 [n_columns = 72900, n_rows = 60000] might cut run time by a factor of 22917.198
surface: Hint: After completion you can recover the desired region via gmt grdcut

However, it does not generate the output file. I have added, removed and changed quite a lot of parameters, but found no indication what is going wrong so far.

My GMT version is 5.4.1.

Cheers,
David

20171009.ztd.rsc - meta data (345 Bytes)

20171009.ztd - xyz input data (2.22 MB)


Replies (9)

RE: Surface does not generate an output file - Added by Paul over 2 years ago

You are converting your table data to a grid and then passing that to surface? Sorry, that makes no sense. Normally, one would run blockmean or blockmedian on the input table to prevent spatial aliasing and then pass that output table to surface. Surface does not READ grids, it generates grids from tables.

RE: Surface does not generate an output file - Added by David over 2 years ago

Actually, blockmedian/surface was what I tried first yesterday, then I tried surface only, then xyz2grd/surface. The xyz2grd approach was the only one successfully converting the input data and since surface did not complain about .grd netCDF format as input I figured this might be the best option to go for obtaining a grid and modifying its resolution.

Blockmedian did not generate any data, either. Here's the call I used with before I started trying something else:

gmt blockmedian 20171009.ztd -R74.2414160/74.917246630000000/42.342141060000000/42.9404720 -I0.000833330000000 -bi3f+L -V > 20171009.xyz

blockmedian: Provides 3, expects 3-column binary data
blockmedian: Processing input table data
blockmedian: W: 74.241416 E: 74.91724663 S: 42.34214106 N: 42.940472 n_columns: 812 n_rows: 719
blockmedian: Input 3 columns via binary records using format fff
blockmedian: No data points found inside the region; no output produced

Values for the -R and -I parameters are taken from the meta data file. The values blockmedian calculates for n_columns and n_rows are each one too large.

RE: Surface does not generate an output file - Added by Paul over 2 years ago

It says no data inside your region, so I would start there first. Maybe you have lat,lon and not lon, lat? If so -: is needed. What does

gmt info 20171009.ztd -bi3f+L

report?

And you are sure your input data are binary records of single-precision floats in little-endian byte order?

RE: Surface does not generate an output file - Added by Paul over 2 years ago

The problem is your input data file. I dont think you know what its format is. Uisng tie -b option you provided shows junk:
gmt info 20171009.ztd -bi3f+L
20171009.ztd: N = 194099 <1.26297736168/2.1872253418> <1.26153075695/2.1872241497> <1.26609158516/2.18690061569>

The file size is 2329192 byte which is not cleanly divisible by 3 (lon, lat, z) regardless of item size. Are you sure these are not just z values that range from 1.25 to 2.18?

RE: Surface does not generate an output file - Added by David over 2 years ago

It might well be that the file consists of a matrix of z values. The documentation just states that the values are given in "given in a grid binary format (4-byte float little endian, name convention YYYYMMDD.ztd)":
ftp://stella.ncl.ac.uk/pub/chen/ReadMe.pdf

As said before, xyz2grd with the aforementioned parameters generates a perfect grid. I just need to increase its resolution by interpolation.

Alternatively, can I import such a matrix of z values with blockmedian/surface (using boundary box coords and pixel size are given in the .rsc file)?

Thanks for the support so far!

RE: Surface does not generate an output file - Added by Walter over 2 years ago

If xyz2grd works fine, then use grdsample to resample the grid to a finer mesh.

RE: Surface does not generate an output file - Added by Joaquim over 2 years ago

David wrote:

I just need to increase its resolution by interpolation.

You might get a nicer (smoother grid) looking grid but you won't get a higher resolution one. No miracles here.

RE: Surface does not generate an output file - Added by David over 2 years ago

Thanks Walter, grdsample works.

Actually, the goal is simply to use grdmath to subtract the resulting grid from another one of different resolution. My idea was to increase the resolution to be able to grdcut both files to the same extent, so that grdmath does not return the "grid files not of same size" error. Unfortunately, this still doesn't work. Is there a way to 'co-register' two grids so that their extent and pixel size is exactly equal?

RE: Surface does not generate an output file - Added by Suresh over 1 year ago

Dear All

I used the following command that helped me converting *.ZTD files to *.GRD files using GMT.

gmt xyz2grd 20180721.ztd -G20180721.grd -RLT74/15/4801/4801 -I0.000833330000000/0.000833330000000 -di0 -ZTLf

gmt xyz2grd input.ztd -Goutput.grd -RLT"min_longitude/Max_Latitude/Width/Height -I"Pixel_X/Pixel_Y" -di0 -ZTLf

Regards,

Suresh Devaraj

(1-9/9)