As I was testing a grdmath macro to obtain Parsons and Sclater [1977] depths from an age grid, I noticed something odd. If I run

gmt grdmath -R200/240/40/60 @earth_age_01m_g PS77 = depth_ps77.grd

then the grid is correct with a range in depths from 2535 to 5356 meters. However, grdinfo says a bit more:

...
depth_ps77.grd: v_min: 2535.00390625 v_max: 5356.30371094 name: z
depth_ps77.grd: scale_factor: 1 add_offset: 0
depth_ps77.grd: Default CPT: @earth_age.cpt

Because the default CPT inherited from the age grid is passed along, and that CPT is set to go from 0 to 340 Myr, trying to make a simple map fails:

I have to specify a master CPT for this to work:

It is not immediately obvious to me when we should wipe the incoming CPT. Well, it is in the sense that we are concerting unit from Myr to m and thus the old CPT should be irrelevant, but grdmath does not know that. Even a simple operation that does not change the units will fail due to the new range:

gmt grdmath -R160W/120W/40/60 @earth_age_01m_g/ 500 SUB = t.grd

would not plot a black ocean map. So there seems to be two possibilities here:

1. grdmath should always wipe the default CPT setting in the output grid
2. grdmath should leave it along and we write a Note in the documentation to explain the problem.

I think we have to go with (1) here. It is a relatively obscure problem and people will not read that section and just be frustrated why their basic plot is blank. I think this is the only module where this sort of thing can happen (unit change or wild range change). Any opposing voices, @GenericMappingTools/core ?