MOBT-689 (Pt2): Spot forecast subsetting using a neighbour cube #7
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…a plugin (metoppv#1996) * Move neighbour_finding_method_name function out of the NeighbourSelection plugin into a new spot data utilities file. This is reused in the spot-extraction CLI, soon to be in the plugin, and should be made more common. * Move check_grid_match into metadata utilities along with the hash generation code which is more logical. This removes imports from the spot_extract file for other plugins that use this functionality. * Move all functionality from the spot-extract CLI to a wrapper class that can be invoked by the CLI. Still needs doc-strings, tidying up, any potential rationalisation, and unit tests for the new class. * Add unit tests for the SpotManipulation plugin which has taken on logic and calling of other plugins that was previously done in the CLI layer. * Fix up dz_rescaling code and apply_height_adjustment CLI which use the neighbour_finding_method_name method which was previously part of the NeighbourFinding plugin but which is now a standalone utility. Update the plugin which the spot_extraction CLI calls. * Resolves doc-string error highlighted by sphinx. * Change test paramerisation to help with testing spot forecast subsetting in subsequent PR. * Additional tests for realization collapse and for percentile extraction directly from realization data. Modifies the test in spot_manipulation for selecting the percentile method to check if data is actually masked, rather than just of masked type. This will enable the fast method to be used in more cases. * Rename neighbour_finding_method_name to get_neighbour_finding_method_name. * Review changes.
…g a neighbour cube via the spot-extraction CLI / SpotManipulation plugin.
…forecast to the sites defined in a neighbour cube with valid IDs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
NOTE: Wait for metoppv#1996 to be merged prior to review so this PR can also be moved from my fork to the trunk.
Allows a user to subset an existing spot-forecast via the spot-extraction CLI using a neighbour cube. This will allow us to apply a verification neighbour cube to the end-of-chain forecasts in the preverspot steps to produce a much smaller and controlled set of sites for verification. It removes the need for the preverspot step in the suite to be aliased to different commands for different steps in the chain.
This subsetting is performed using a coordinate selected by the user, with the doc-strings indicating this should be an ID coordinate (e.g. wmo_id or met_office_site_id), rather than e.g. altitude. I have not designed this to handle float comparisons, nor constraining on multiple coordinates as would be required if sites were to be extracted using latitude + longitude.
Acceptance test data: metoppv/improver_test_data#46
Testing: