EHN: Vectorising gate2geographic_location()#450
Open
billetd wants to merge 2 commits into
Open
Conversation
Collaborator
|
Code looks fine, I'll test when I can. We should maybe think about why it's returning the values to different significant figures, and maybe decide on the sig fig we want to use. |
This file contains hidden or 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
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.
Scope
This PR vectorises the
gate2geographic_location()function, and all relevant child functions (including geocentric conversion and virtual height model functions) to enable calculations of multiple beam/range combos at once. I wanted this for a project I'm working on because I end up iterating over a lot of different range gates. This provides a big speed up that scales the more beams/gates you need. This touches a fair few different spots, mostly just to ensure it handles both numpy arrays OR single scalars. This means it should not affect any upstream code that also uses these functions.Currently, this makes the assumption that all the beams/gates come from the same radar and record (constant
stid,rsep, andfrang). It could be updated to handle that down the line, but that would be a lot more work.Approval
Number of approvals: 2
Test
Output:
To show this produces the exact same results as before, you can run this test code on the develop branch (for the single beam/gate only):
Output: