GMT

Just to add;

Doing a

grdedit -J.. old.nc -Gnew.nc

the projection information is actually written to old.nc, but new.nc is not created (modifies existing file whether -G is given or not)

Yes, I forgot to mention that. I observed the same.

Hmm, I was not even aware of grdedit -G and imo that's a superfluous option that doesn't deserve the work of making it work. If anyone wants to keep a copy of the original it's easy, make a copy.

Yes, Joaquim, that can be done, but it should not be necessary. Besides, the grid is written again, from scratch, irrespectively, so the -G option actually serves a purpose, because it is faster that way.

But what I find alarming is that when I add -Vd all the debug info looks good, as if a new file is written. But it is not. That means that somewhere deep in the weeds of GMT_Write_Data something goes terribly wrong. And this can have serious effects on all GMT programs ... at least the ones handling grids.

grdedit: Object ID 0 : Registered GMT Grid File antarctica_ice_speed_900m.nc as an Input resource with geometry Surface [n_objects = 1]
grdedit: api_begin_io: Input resource access is now enabled [container]
grdedit: api_import_grid: Passed ID = 0 and mode = 1
grdedit: Grid is Cartesian
grdedit: GMT_End_IO: Input resource access is now disabled
G: 1 ./k.nc antarctica_ice_speed_900m.nc ./k.nc
grdedit: Editing parameters for grid antarctica_ice_speed_900m.nc:
grdedit: Decode and change attributes in file antarctica_ice_speed_900m.nc
grdedit: api_begin_io: Input resource access is now enabled [container]
grdedit: api_import_grid: Passed ID = 0 and mode = 2
grdedit: Reading grid from file antarctica_ice_speed_900m.nc
grdedit: processing at most 480 (10x48) chunks at a time (30.9 MiB)...
grdedit: packed z-range: [0,3916.32]
grdedit: Grid is Cartesian
grdedit: Chosen boundary condition for all edges: natural
grdedit: Set boundary condition for all edges: natural
grdedit: Set boundary condition for left   edge: natural
grdedit: Set boundary condition for right  edge: natural
grdedit: Set boundary condition for bottom edge: natural
grdedit: Set boundary condition for top    edge: natural
grdedit: GMT_End_IO: Input resource access is now disabled
grdedit: GMT_End_IO: Input resource access is now disabled
grdedit: Reset region in file antarctica_ice_speed_900m.nc to -2.8e+06/2.7998e+06/-2.7998e+06/2.8e+06
grdedit: Reset grid-spacing in file antarctica_ice_speed_900m.nc to 900/900
grdedit: Object ID 1 : Registered GMT Grid File ./k.nc as an Output resource with geometry Surface [n_objects = 2]
grdedit: api_begin_io: Output resource access is now enabled [container]
grdedit: api_export_grid: Passed ID = 1 and mode = 1
grdedit: Updating grid header for file ./k.nc
grdedit: netCDF Library version: 4
grdedit: GMT_End_IO: Output resource access is now disabled
grdedit: Modified grid written to file ./k.nc.
grdedit: gmtapi_garbage_collection: Destroying object: C=0 A=0 ID=0 W=Input F=GMT Grid M=File S=Used P=7ffbd9400890 D=7ffbd9400890 N=antarctica_ice_speed_900m.nc
grdedit: GMTAPI_Garbage_Collection freed 1 memory objects
grdedit: gmtapi_unregister_io: Unregistering object no 0 [n_objects = 1]
grdedit: gmtapi_unregister_io: Unregistering object no 1 [n_objects = 0]
grdedit (gmtlib_free_tmp_arrays): tried to free unallocated memory

No, the easier way was to use GMT_Write_Data with mode = GMT_GRID_ALL when -G is used.
See r16861 (GMT5.3) and r16862 (GMT5.2).

And it now crashes on Windows.

:(

That's odd. Works fine on Mac. And it should also on Windows. The concept is simple.

Two things:

1. I'm using debug builds. Sometimes it makes a difference

1. I know you will smile on this but I've been there really many times (Paul can testify) the fact is that compilers on Mac are too permissive to small memory errors. I lost count to cases where VS detected a problem (often by crashing) that clang did let go. We have one of those with grdimage and MEX/Julia that we have not been able to solve.

Joaquim was testing things like gmt grdedit JP.nc -Jm0.1i -Glixo.grd which definitively crashes since grdedit did not actually read the grid data (only the header) but then tries to write the entire grid to the new file. I fixed this and added some general precautions in the API against that sort of problem for grids and images. In r16865.

Thanks. I thought looked carefully that in all cases the whole grid would be read. But I guess I was not careful enough.
I've backported the same change (r16867) to GMT5.2 (r16869).