-
Notifications
You must be signed in to change notification settings - Fork 300
Trajectory optimisation #1946
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
Trajectory optimisation #1946
Changes from all commits
c8c3151
99d19f1
2ee298f
a580f66
820c120
64a691a
d53d3e2
c731fa6
6397f75
f8fdf28
0cfee0a
2c04b03
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,5 @@ | ||
| * Trajectory interpolation routines are now much faster, in both the linear and | ||
| nearest neighbour schemes. A consequence of this is that the cube being | ||
| interpolated no longer remains lazy. | ||
|
|
||
|
|
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,4 @@ | ||
| # (C) British Crown Copyright 2010 - 2015, Met Office | ||
| # (C) British Crown Copyright 2010 - 2016, Met Office | ||
| # | ||
| # This file is part of Iris. | ||
| # | ||
|
|
@@ -189,13 +189,10 @@ def test_hybrid_height(self): | |
| # Put a biggus array on the cube so we can test deferred loading. | ||
| cube.lazy_data(biggus.NumpyArrayAdapter(cube.data)) | ||
|
|
||
| traj = (('grid_latitude', [20.5, 21.5, 22.5, 23.5]), | ||
| traj = (('grid_latitude', [20.499, 21.501, 22.501, 23.501]), | ||
| ('grid_longitude', [31, 32, 33, 34])) | ||
| xsec = iris.analysis.trajectory.interpolate(cube, traj, method='nearest') | ||
|
|
||
|
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I have altered the numbers here slightly so that the test case is not so unstable. In the reference, the nearest neighbour scheme rounded the grid latitudes to [20, 22, 23, 24]. This should ensure that the standard nearest neighbour scheme yields the same result.
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Although I've just noticed that it doesn't and I need to work out why. |
||
| # Check that creating the trajectory hasn't led to the original | ||
| # data being loaded. | ||
| self.assertTrue(cube.has_lazy_data()) | ||
| xsec = iris.analysis.trajectory.interpolate(cube, traj, method='nearest') | ||
| self.assertCML([cube, xsec], ('trajectory', 'hybrid_height.cml')) | ||
|
|
||
|
|
||
|
|
||
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.
In changing the nearest neighbour scheme 'iris.analysis.interpolate._nearest_neighbour_indices_ndcoords' to 'iris.analysis.Nearest().interpolator', the method of finding nearest points has changed significantly.
'_nearest_neighbour_indices_ndcoords' was a more physical result (used spherical-cartesian coordinate transformations to find the nearest point in 3-dimensional space) but was extremely long-winded, which used up a lot of processing time for each point.
This method is not used in any other functions, so has now become redundant, but may still be useful.
There are options regarding how to proceed with this:
Personally I think it seems a shame to waste it, but differences in real-world results may be so negligible that there is no need to keep it. I would like to know what people think about this.