-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Matrix as grid with changing central meridian doesn't work well for gridline grids #3844
Comments
Will look tomorrow. I know the issue: When we rotate the central longitude the repeated columns at -180 and 180 need to collapse to one. |
So 1-2 days go by, an automatic OS update happened over night, so GMT_LIBRARY_PATH was unset. However, I am missing another step before I can sy import pygmt, something about switching from base to pygmt or a setup step? |
Yes, you need to activate your conda environment by |
The script generates 4 figures. Which one? |
They are all like that (just a sliver near the boundary), I think this one was matrix_g.png |
This makes no sense. Perhaps try |
Makes perfect sense. There was an old gmt.history in the directory I started python: GMT 6 Session common arguments shelfBEGIN GMT 6.2.0 and the python script latched onto that. SHould not pygmt start a new session and no gmt.history is used? |
You mean the gmt begin -C?
Does it also ignore gmt.history? |
So back to the original issue: Since we are passing reference we simply use the grid. It gets projected, in gmt_grd_project there will be loops over input and output nodes (you remember this from last week). So there will be two sets of meridians taht are used (lon = -180 and lon = 180) which are exactly the same. So those should technically be given a 0.5 weight so that in averaging many nodes they should not count more. Normally (i.e., grdfiles) we do not see this (or possibly never noticed) because we read int the grid with rotation, so the repeated columns are at the two separate sides. Now they show up in the middle. I will see if ti is possibly to insert the weight of 0.5. |
If you start with begin -C then clearly we leak that through. Give it a test bu using my history file above and confirm the problem. |
Testing a fix for this. Now it passes: versus before it was
Green: 0.0050802491 1.3 All tests still pass so I am making a PR. |
Since the history file is read in GMT_Create_Session, it has already been ingested when begin -C is parsed. Thus, I need to reset the history. I could not recreate the problem on the command line, so suspect it is interfering with the matri/grdimage stuff. |
There should be no instances where an old gmt.history file should be used by a new modern script, -C or not. I think I will always reset history when gmt begin is called. It is different for the settings. |
See troubles found in #3844.
See troubles found in #3844. Co-authored-by: Paul Wessel <[email protected]>
Closed by #3849. |
Full script that generated the error
The script generates 4 maps, for pixel or gridline grids passing as grid or matrix:
Use the command below to compare the two maps of pixel-registered grid/matrix. The RMS is zero. So passing grid or matrix give the same results:
Use the command below to compare the two maps of pixel-registered grid/matrix.
The RMS is non-zero. Here is the diff image. There are tiny difference along the x=180 line. Perhaps a 0.5 grid offset?
The text was updated successfully, but these errors were encountered: