Incoherent gridline behaviour

PlanetGus · February 8, 2021, 10:00pm

On gmt v. 6.2.0_bb0b2d9_2020.12.14 with macOS Big Sur

Hi,
I’m trying to plot a time-series with two set of annotations for the y-axis using daily data.
The primary axis is supposed to :

not annotate
tick every months
add a gridline every months

The secondary axis is supposed to :

annotate every year
tick every year
add a gridline every year

I hoped to have a thicker line for the secondary grid lines, but if it’s too complicated, I can also not use it as it is redundant with the primary ones (once per year).

At any rate, at first I tried this :

gmt grdimage ${region} ${projection} $FILE?var -Bxa20f10g10 -Bpyf1Og1O -Bsya1Yf1Yg1Y -BWSen

as well as 12O 12o 1y…

The annotations are fine, the ticks seem to be too … but the grid lines are either shifted and inconsistently spaced or plotted daily (or so it seems).

Do you have a suggestion ?

See picture :
On left : -Bpyf1o -Bsya1Y
On right : -Byf1og12y

MarceloBanik · February 8, 2021, 11:14pm

using psbasemap appears to work:

gmt psbasemap -R0/100/2020-06-01T/2021-06-01T -JX10c/10cT -Bxa20f10g10 -Bpyf1Og1O -Bsya1Yf1Yg1Y -BWSen --MAP_GRID_PEN_PRIMARY=thinner,grey --MAP_GRID_PEN_SECONDARY=thin,black -png test

test1456×1282 8.94 KB

I didn’t expect that grdimage will do something different, but I didn’t have any file here to try.
Is it possible to share some simple data to test it?
using gmt 6.2.0_68e0098_2021.01.19

PlanetGus · February 8, 2021, 11:32pm

Sure …
Sorry for the delay … I had to extract a sample and upload it on a tiers service :

The data are Sea-Surface Temperature averaged in the Pacific equatorial band (so it has the dimension of longitude x time)
lon1 = 110
lonN = 280
time1 = 1980-01-01
timeN = 1984-01-01 (I think , I truncated it bluntly)

the variable to plot is eqb_nc_sst

MarceloBanik · February 9, 2021, 1:22am

appears that it get a wrong TIME_EPOCH:

$ gmt grdinfo sample_data.nc
grdinfo [WARNING]: TIME_EPOCH format is invalid. Default assumed.
grdinfo [WARNING]: A correct format has the form [-]yyyy-mm-ddThh:mm:ss[.xxx]
grdinfo [WARNING]: or (using ISO weekly calendar) yyyy-Www-dThh:mm:ss[.xxx]
grdinfo [WARNING]: An example of a correct format is: 2000-01-01T12:00:00
grdinfo [WARNING]: Time units [days since 0000-01-00 00:00:00.0 +0000]] in grid not recognized, defaulting to gmt.conf settings.
sample_data.nc: Title:
sample_data.nc: Command:
sample_data.nc: Remark:
sample_data.nc: Gridline node registration used [Cartesian grid]
sample_data.nc: Grid file format: nf = GMT netCDF format (32-bit float), CF-1.7
sample_data.nc: x_min: 110 x_max: -80 x_inc: 0.25 name: longitude n_columns: 681
sample_data.nc: y_min: 0 y_max: 126144000 y_inc: 86400 name: time [days since 0000-01-00 00:00:00.0 +0000] n_rows: 1461
sample_data.nc: v_min: 0 v_max: 0 name: eqb_nc_sst
sample_data.nc: scale_factor: 1 add_offset: 0
sample_data.nc: format: classic

I try to convert to xyz and back to grid to set the TIME_EPOCH, but I get only NaN for the Z value:

gmt grd2xyz “sample_data.nc?eqb_nc_sst” | gmt xyz2grd -R110/280/1980-01-01T/1984-01-01T -I0.25/86400 -f0f,1t -Gtest.nc

Anyway, to test the grid, I could use this test.nc garbage:

gmt makecpt -Crainbow > test.cpt
gmt grdimage test.nc -R110/280/1981-01-01T/1983-01-01T -JX10c/10cT -Ctest.cpt -Bxa20f10g10 -Bpyf1Og1O -Bsya1Yf1Yg1Y -BWSen --MAP_GRID_PEN_PRIMARY=thinner,grey --MAP_GRID_PEN_SECONDARY=thin,black -png test

appears that the grid is ok, a primary every months and a secondary every year:

what command (including values) are you using?
It could be useful to know the gmt defaults that you are using.

PlanetGus · February 9, 2021, 1:35am

Hum weird,

maybe the time goes from 0 to length(time)
with

gmt gmtset TIME_EPOCH 1980-01-01

MarceloBanik · February 9, 2021, 10:33am

after some adjust in the netcdf file and using:

gmt makecpt -T294/304/1 > test.cpt

resulting:

It appears to me that the grid is ok, a primary every months and a secondary every year.

PlanetGus · February 9, 2021, 3:15pm

Using the same kind of data (relative time TIME_EPOCH 1980-01-01)

gmt grdimage -R$lon1a/$lon1b/$day1/$day2 -JX${w1}cd/-${height}ct $FILE?eqb_cl_sst -Bxa20f10g10 -Bpyf1O -Bsya1Yf1Y -BWSen

Gives expected result.

Any g addition to either Bpy or Bsy fill the plot with gridlines every day (unit) instead of wanted O or Y.
Could it be related to the issue I reported with math on Github ?

MarceloBanik · February 9, 2021, 4:02pm

here I didn’t have ploblems do add g to either Bpy or Bsy, as I showed before.
I think I get your example right here:

$ gmt math -o0 -T1980-01-01T/2019-12-31T/4y T =
1980-01-01T00:00:00.000000000
1984-01-01T00:00:00.000000000
1988-01-01T00:00:00.000000000
1992-01-01T00:00:00.000000000
1996-01-01T00:00:00.000000000
2000-01-01T00:00:00.000000000
2004-01-01T00:00:00.000000000
2008-01-01T00:00:00.000000000
2012-01-01T00:00:00.000000000
2016-01-01T00:00:00.000000000

could you share your defaults?

gmt defaults > defaults.txt

What I have here is:
defaults.txt (5.1 KB)
Note that I used “T” in -JX10c/10cT to specify a time axes and appears that you used “t”. Could it be the problem? What exactly is your -JX${w1}cd/-${height}ct ?

PlanetGus · February 9, 2021, 4:35pm

These are numeric values calculated with bc … not an issue really

I see that you’re using the “stable” version (GMT6.1), maybe a bug in dev6.2 ?

I’ll take a moment this afternoon to compare your default file … thanks

MarceloBanik · February 9, 2021, 4:50pm

working with gmt 6.2.0_68e0098_2021.01.19:

$ gmtswitch 6.2.0;gmt --version;gmt math -o0 -T1980-01-01T/2019-12-31T/4y T =
6.2.0_68e0098_2021.01.19
1980-01-01T00:00:00.000000000
1984-01-01T00:00:00.000000000
1988-01-01T00:00:00.000000000
1992-01-01T00:00:00.000000000
1996-01-01T00:00:00.000000000
2000-01-01T00:00:00.000000000
2004-01-01T00:00:00.000000000
2008-01-01T00:00:00.000000000
2012-01-01T00:00:00.000000000
2016-01-01T00:00:00.000000000

maxrjones · February 9, 2021, 5:11pm

I think you’re probably using different OS’s. When I build 6.2.0_68e0098_2021.01.19 on MacOS gmt math -o0 -T1980-01-01T/2019-12-31T/4y T = does not work and gives the same bug as reported recently on GitHub.

PlanetGus · February 9, 2021, 6:05pm

@maxrjones :
back to the -Bg options problem, do you think it is also an OS issue ?

Nothing really unusual between my default parameters / script and the ones @MarceloBanik shared to help me.

MarceloBanik · February 9, 2021, 7:31pm

gmt grdimage test.nc -R110/280/1981-11-01T/1982-02-01T -JX10cd/10cT -Ctest.cpt -Bxa20f10g10 -Bpyf1Og1O -Bsya1Yf1Yg1Y -BWSen --MAP_GRID_PEN_PRIMARY=thinner,grey --MAP_GRID_PEN_SECONDARY=thin,black --TIME_INTERVAL_FRACTION=0.1 -png test1
results:

changing -R110/280/1981-11-01T/1982-02-01T to -R110/280/373420800/381369600

gmt grdimage test.nc -R110/280/373420800/381369600 -JX10cd/10cT -Ctest.cpt -Bxa20f10g10 -Bpyf1Og1O -Bsya1Yf1Yg1Y -BWSen --MAP_GRID_PEN_PRIMARY=thinner,grey --MAP_GRID_PEN_SECONDARY=thin,black --TIME_INTERVAL_FRACTION=0.1 --TIME_UNIT=s --TIME_EPOCH=1970-01-01T00:00:00 -png test2

results:

changing -JX10cd/10cT to -JX10cd/10ct

gmt grdimage test.nc -R110/280/373420800/381369600 -JX10cd/10ct -Ctest.cpt -Bxa20f10g10 -Bpyf1Og1O -Bsya1Yf1Yg1Y -BWSen --MAP_GRID_PEN_PR
IMARY=thinner,grey --MAP_GRID_PEN_SECONDARY=thin,black --TIME_INTERVAL_FRACTION=0.1 --TIME_UNIT=s --TIME_EPOCH=1970-01-01T00:00:00 -png test3

results:

what I suspect is a grid every day.
Then I suspect you could try use -JX${w1}cd/-${height}cT

PlanetGus · February 9, 2021, 8:13pm

That works !
Thanks.

It is strange because the script used to work fine in GMT5… I guess modern mode is more rigorous about this.

MarceloBanik · February 9, 2021, 8:59pm

I think it should have worked with -JX${w1}cd/-${height}ct.
So it appears to be a bug.

pwessel · February 9, 2021, 10:01pm

I dont think it is a but. Capital T is required if you want an axis to be temporal.

PlanetGus · February 9, 2021, 10:06pm

This is weird though

With -J[...]ct (and timestamps given relative to TIME_EPOCH) everything works except for -Byg[..] (no problem with x). The gridlines are systematically plotted at “unit”.

With -J[...]cT (and timestamps given in absolute format) everything works.

MarceloBanik · February 9, 2021, 10:58pm

from https://docs.generic-mapping-tools.org/latest/gmt.html#r-full
For calendar time coordinates you may either give (a) relative time (relative to the selected TIME_EPOCH and in the selected TIME_UNIT; append t to -JX|x)
Then I think that
-R110/280/373420800/381369600 -JX10cd/10ct --TIME_UNIT=s --TIME_EPOCH=1970-01-01T00:00:00
should have worked.

pwessel · February 10, 2021, 12:22am

I agree that it says that in the docs. I will try to learn why the 1O gets (probably) converted to double and gives 1 (second).

PlanetGus · February 10, 2021, 10:51pm

@pwessel, I’m not sure we’re talking about the same thing…

I have 2 set of data where time starts at 0 (relative to TIME_EPOCH 1980-01-01 , TIME_UNIT d)

A netcdf file (grdimage)
A text file (plot)

When I try to plot my data I do

# Case 1 (wanted)
gmt grdimage -R0/360/1980-01-01/1984-01-01 -JX10cd/-10ct file.nc"?var" -Bxa20f10g10 -Bpyf1og1o -Bsya1yf1yg1y -BWSen
gmt plot tmp.txt -W2,black -Gred -Sc -t50 

# Case 2 (not ideal)
gmt grdimage -R0/360/0/1461 -JX10cd/-10ct file.nc"?var" -Bxa20f10g10 -Bpyf1og1o -Bsya1yf1yg1y -BWSen
gmt plot tmp.txt -W2,black -Gred -Sc -t50 

# Case 3
gmt grdimage -R0/360/1980-01-01/1984-01-01 -JX10cd/-10cT file.nc"?var" -Bxa20f10g10 -Bpyf1og1o -Bsya1yf1yg1y -BWSen
gmt plot tmp.txt -W2,black -Gred -Sc -t50

Case 1 : JX()d/()t (x : geo-degrees , y: relative time)

-R is given with absolute time regardless.
Both grdimage and plot are displayed as expected, except for the grid lines on y-Primary and y-Secondary axis. They are too dense and completely fill the picture (TIME_UNIT probably switched in seconds)
Apart from the grid line, everything is correct. (NB x-axis grid lines are fine too)

Case 2 : same

-R is given with relative time.
It makes no difference compared to Case 1, so I’d rather stick to the Case 1 as the input format doesn’t require additional calculation.

Case 3 : JX()d/()T (x : geo-degrees , y: absolute time)

-R is given with absolute time.
grdimage is still fine. The gridlines appear correctly, but plot is off-grid.