-
Notifications
You must be signed in to change notification settings - Fork 284
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
Support cartopy 0.20 and proj 8.1.0 #4331
Conversation
[318.935163, 318.935163, 318.935163], | ||
[318.92881733, 318.92881733, 318.92881733], | ||
[318.92881733, 318.92881733, 318.92881733], | ||
[318.92881733, 318.92881733, 318.92881733], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't identify the root cause for the change in numbers here... hence why I've introduced a minimum pin for cartopy
in iris
(after all, this is a major release update of proj
)
We either accept this change "as is"... or dig deeper.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the provenance of the original numbers in the test? Assuming these are degrees longitude the difference is 0.00635deg ~ 700m on the equator.
Do we at least understand why the original test array was 2 rows of 318.936829 and 1 row of 318.935163, while the replacement is 3 identical rows of 318.92881733?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the provenance of the original numbers in the test? Assuming these are degrees longitude the difference is 0.00635deg ~ 700m on the equator.
I don't think there is any significance to the values being tested in the array, other than a random snapshot. @pp-mo Any ideas on the history of this one?
I think the philosophy of the test is rather weak, in that it's attempting to give "some level" of confidence that nothing has changed... but when something does change (like now) there is no context to determine whether the change is significant and/or valid.
I'm more inclined to trust a plot rather than raw numbers for this type of integration test 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the philosophy of the test is rather weak, in that it's attempting to give "some level" of confidence that nothing has changed... but when something does change (like now) there is no context to determine whether the change is significant and/or valid.
👍 😁
@pp-mo Any ideas on the history of this one?
I don't think there is anything special here, just a desire to check a small section of individual points, not just statistics over the whole array.
An actual change equivalent to 100's of metres does seem rather large though. Maybe the default ellipsoid for this changed ?
I would have suggested that we should apply a more sensible tolerance to AssertArrayEqual.
Its default is 6DP, so that ~2cm (!!)
But to tolerate this we would need to have decimal=1
.
0.1 degrees ~1700m does seem rather large.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then again... the plots are rather different too...
The left plot is cartopy
0.19.0.post1, and the right plot is cartopy
0.20.0
The six subplots within each plot are the six level
s [0..5]
in the timeseries, where level[0]
is the top-left and level[5]
is bottom-right.
Apologies, forgot to add a colorbar, oops.
There is some similar structure there, but the differences are (to me) significant.
At this point, I can't confirm what's right. Any clues @pp-mo ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actual values shouldn't change. But the location of the values can.
how did this manage to match on the array stats, I wonder ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've rebased, as this PR went stale...
I'm still in favour of creating an issue to cover this, if that seems like a pragmatic compromise. Then we can dedicate some time to digging a bit further to understand the root cause of the issue (if possible), but bank this PR and move on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm still in favour of creating an issue to cover this, if that seems like a pragmatic compromise. Then we can dedicate some time to digging a bit further to understand the root cause of the issue (if possible), but bank this PR and move on.
If we're honest, that's effectively saying we agree this change isn't a problem, and maybe we'll get round to working out what caused it at some point in the future. I'm fine with that if everyone else is.
However: if this is agreed to be a real concern then I'm very uncomfortable merging into main
. If it's a real concern and we don't have time now then we should put a maximum pin on Cartopy, no matter how horrible that prospect is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does the fact that this is in experimental
influence how much we should worry about this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rcomer Nice point, it's experimental... I'm not too precious about it.
Also, the fact that this issue is isolated in one test and not an issue peppered throughout Iris is somewhat comforting.
lib/iris/tests/results/unit/analysis/cartography/project/TestAll/cube.cml
Show resolved
Hide resolved
@jamesp I'm inclined to remove myself from review/assign + let you take it on instead. |
@jamesp Someone needs to review and merge SciTools/test-iris-imagehash#53 😄 |
I've merged that + re-spun the tests. |
Benchmark failure is very strange - it seems to be installing proj 7 instead of proj 8, but the lockfile at HEAD looks like it has proj 8 |
installed_hash = self._get_installed_commit_hash() | ||
if installed_hash: | ||
log.info(f"Clearing conda environment for {self.name}") | ||
self._cache._remove_cache_dir(installed_hash) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks to @jamesp for this magic fix 🎉
b441d02
to
de38d1c
Compare
Let's bank the "new" numbers, and create an issue to investigate this. Issue to cover : #4346 |
* Updated environment lockfiles * Support cartopy 0.20 and proj 8.1.0 (#4331) Co-authored-by: Lockfile bot <noreply@github.com> Co-authored-by: Bill Little <bill.james.little@gmail.com>
🚀 Pull Request
Description
This PR includes the changes to support
cartopy
0.20 andproj
8.0.1.Also see the companion PR SciTools/test-iris-imagehash#53 for the imagehash changes, which will require to be merged for this PR to pass.
Ref: SciTools/cartopy#1252
Consult Iris pull request check list