-
Notifications
You must be signed in to change notification settings - Fork 225
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
Re-caching GMT remote files #495
Conversation
Great, it's just 23 failures instead of 43 now. All of the |
Most of the 23 failures are easy to fix, except two The following Python script gives me a white-black map with GMT 6.0.0: import pygmt
from pygmt.datasets import load_earth_relief
pygmt.print_clib_info()
grid = load_earth_relief()
fig = pygmt.Figure()
fig.grdimage(grid, cmap='earth', projection='W0/6i', V='l')
fig.show(method="external") Warnings:
It even doesn't work with PyGMT v0.1.1 + GMT 6.0.0. |
Yeah, I was getting that a while ago too, sometimes it's purple 😆. I think it's fine in GMT master though. |
Yes, but when we release PyGMT v0.1.1, everything is fine with GMT 6.0.0. I checkout PyGMT v0.1.1, and test it with the GMT 6.0.0 I built locally, I still get the white-black map. |
Just realized that the two tests |
FYI, the two tests |
Hmm, might be that you've cached the pixel registered grids locally, and the cache was just invalidated today. Probably best to run |
I can't reproduce the failures anymore. They all work well for me. Perhaps I can update the baseline images and also the numbers to make all the CI green but not merge the branch. It seems easier for us to check GMT master and #476, and decide if we really want a v0.1.2 release. |
Do you mean just cherry-picking the changes here on top of whatever branch we're working on? |
Here are some tests I just did locally. Currently, there are 23 failures for GMT 6.0.0. To make all the tests pass, I need to update the following files:
After these changes, all tests pass. I then temporarily changed
Among the 15 failures:
Then I updated the 15 images above, cherry-picked the changes in PR #476 (assuming this branch is correct), and ran the tests again. I saw the following failing images:
The 14 grdview tests are failing due to the same reason (unknown yet). Here is an example. New image if PR #476 is merged: Perhaps because the default projection depends on the grid type (either |
Ok, I think we can agree to not merge in any baseline png image changes, in case anything happens before GMT 6.1.0 release.
Yes, good spotting, we'll definitely need to update these
I wouldn't assume that the branch is correct yet 😆, I still need to make sure things work if Just to add that it might be possible to keep the same old grdview baseline images if we force those tests to use |
Perhaps the best way to minimize image updates is,
|
I'm okay with this. Could do it in this PR even. I was trying to figure out how to parametrize the tests to use
No strong opinion on this, I don't really mind when PyGMT v0.1.2 gets released, either before or after GMT 6.1.0 is fine. We should make sure to pin to GMT <= 6.1.0 on conda-forge, i.e. PyGMT v0.1.2 is the last version to support GMT 6.0, and contains some minor changes to make it compatible with GMT 6.1.
Looking forward to this 🚀 |
I think we can close this since Azure Pipelines isn't used anymore and we've updated to GMT 6.1.0 in #507. |
Description of proposed changes
The earth relief data for GMT 6.0.0 was just changed back to gridline registration. It means that GMT<=6.0.0 uses gridline-registered earth relief data, while GMT>=6.1.0 will uses pixel-registered earth relief data by default.
Related to #451.
Reminders
make format
andmake check
to make sure the code follows the style guide.doc/api/index.rst
.