-
Notifications
You must be signed in to change notification settings - Fork 87
[1488] Support frequency nominal dim in consolidate functions #1520
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
base: main
Are you sure you want to change the base?
[1488] Support frequency nominal dim in consolidate functions #1520
Conversation
for more information, see https://pre-commit.ci
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1520 +/- ##
==========================================
+ Coverage 83.52% 84.95% +1.43%
==========================================
Files 64 79 +15
Lines 5686 7013 +1327
==========================================
+ Hits 4749 5958 +1209
- Misses 937 1055 +118
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| # and obtain the echodata group path corresponding to encode_mode | ||
| ed_beam_group = retrieve_correct_beam_group(echodata, waveform_mode, encode_mode) | ||
|
|
||
| # check that source_Sv at least has a channel dimension | ||
| if "channel" not in source_Sv.variables: | ||
| raise ValueError("The input source_Sv Dataset must have a channel dimension!") | ||
| dim_0 = list(source_Sv.sizes.keys())[0] | ||
|
|
||
| # Select ds_beam channels from source_Sv | ||
| ds_beam = echodata[ed_beam_group].sel(channel=source_Sv["channel"].values) | ||
| if dim_0 in ["channel", "frequency_nominal"]: | ||
| ds_beam = echodata[ed_beam_group].sel({dim_0: source_Sv[dim_0].values}) | ||
| else: | ||
| raise ValueError( | ||
| "The input source_Sv Dataset must have a channel or frequency_nominal dimension!" | ||
| ) |
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 this implementation dim_0 can be anything that is in the first position (index 0) in the ds dataset keys. In theoryds can come from different sources, so there is no guarantee that the first key would be channel or frequency_nominal. Since you check if dim_0 in ["channel", "frequency_nominal"] downstream anyways, how about checking if the dimension contains one of these two options before proceeding?
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 not sure I understand where the check should be. Instead of checking here are you saying it would be better earlier in the add_splitbeam_angle function?
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 it's more that dim_0 = list(source_Sv.sizes.keys())[0] may grab other dimensions if the order of dimension is different from having channel or frequency_nominal at the first position. It's better to search for those in the dimension list I think.
echopype/consolidate/api.py
Outdated
| dim_0 = list(ds.sizes.keys())[0] | ||
| if echodata["Sonar/Beam_group1"][dim_0].equals(ds[dim_0]): | ||
| beam_group_name = "Beam_group1" | ||
| else: | ||
| beam_group_name = "Beam_group2" |
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.
Also, the current implementation
if echodata["Sonar/Beam_group1"][dim_0].equals(ds[dim_0]):
beam_group_name = "Beam_group1"
else:
beam_group_name = "Beam_group2"
is a weird setup in terms of Beam_groupX selection. This is a larger issue so no immediate actions required under this PR, but I will note this in a separate issue.
| def test_add_splitbeam_angle_w_dim_swap(sonar_model, test_path_key, raw_file_name, test_path, | ||
| paths_to_echoview_mat, waveform_mode, encode_mode, | ||
| pulse_compression, to_disk): |
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.
This new test is largely identical with the existing test_add_splitbeam_angle, and the content of that test was to make sure the split beam angle computation is correct. I think it's a bit meddling the water to repeat the same thing here, since dimension swap is not part of the split beam calculate.
Could you slim this down to just testing the dimension swap?
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.
There is already a test for the swap_dims_channel_frequency and I didn't make any changes to that function but do you think it needs more coverage? This test was meant to cover the changes I made to 'test_add_splitbeam_angle' and make sure the split beam angle computation was correct when the dims are swapped. Maybe it would be better to just add a dim swap test case to the existing test_add_splitbeam_angle 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.
adding one test to go through the swap_dims_channel_frequency step and then add_splitbeam_angle would be great. I think making it a separate test from test_add_splitbeam_angle which tests the function outputs would be a good idea.
| def test_add_depth_EK_with_beam_angles_with_different_beam_groups_and_dim_swap( | ||
| file, sonar_model, compute_Sv_kwargs, expected_beam_group_name, ek80_path | ||
| ): |
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.
Similar to my comment on test_add_splitbeam_angle, I think it's better to not repeat the same test and create a new one focusing on the dimension swap.
leewujung
left a comment
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.
@dbashford-NOAA : Thanks for the PR. Sorry it took a while for me to get to this.
I made a few suggestions that I think will improve the robustness and the tests.
Could you also add a test for add_location to make sure things flow through even with dimension swap? Thanks.
Please request my review once you're done with the above.
| ds = ep.consolidate.swap_dims_channel_frequency(ds) | ||
| for group in ed["Sonar"]['beam_group'].values: | ||
| ed[f"Sonar/{group}"] = ep.consolidate.swap_dims_channel_frequency(ed[f"Sonar/{group}"]) | ||
|
|
||
| ds_all = ep.consolidate.add_location(ds=ds, echodata=ed) |
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.
@dbashford-NOAA : these made me realize that, even though channel and frequency_nominal are not explicitly used in add_location, the interpolation would actually require the dimensions to be aligned for the function to work. The intention for the issue is to make all functions under ep.consolidate compatible with ds_Sv that already has the dimension swapped, so I thinks we should make the add_location able to handle this disjoint (between ed dimension channel and ds_Sv dimension frequency_nominal)? Then the function should run through with ds_all = ep.consolidate.add_location(ds=ds, echodata=ed) without having to swap the ed dimension.
Let me know if I misunderstood anything here.
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.
To make sure I understand, you're saying that add_location should work with the ds dims swapped but without calling swap_dims_channel_frequency on each ed beam group? If so, should all ep.consolidate functions work that way?
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.
(Somehow I missed your response...)
Yes I think all ep.consolidate functions should work that way. Basically the functions should work with either channel or frequency_nominal as a coordinate.
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
Resolves #1488
dim_0so frequency nominal can be supported in place of channel