Skip to content
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

Generalize assignment of beam coordinate var attributes #480

Merged
merged 2 commits into from
Nov 8, 2021

Conversation

emiliom
Copy link
Collaborator

@emiliom emiliom commented Nov 6, 2021

Unified where the attributes for the core beam coordinate variables (frequency, ping_time, range_bin) are set. I've created a new DEFAULT_BEAM_COORD_ATTRS dict in set_groups_base.py that declares these common attributes and their values, then import that variable in the various set_groups_x.py modules. This PR implements that change for ek60, ek80, azfp.This abstraction/centralization will reduce the potential for variability across sensors and make it a tiny, tiny bit easier to roll out support for new sensors in a consistent fashion.

Also added a long_name attribute to range_bin, partly addressing #373

@emiliom emiliom requested a review from leewujung November 6, 2021 18:50
@codecov-commenter
Copy link

codecov-commenter commented Nov 6, 2021

Codecov Report

Merging #480 (9ccdf36) into dev (4c77300) will decrease coverage by 4.39%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##              dev     #480      +/-   ##
==========================================
- Coverage   76.66%   72.27%   -4.40%     
==========================================
  Files          38       16      -22     
  Lines        3339     2287    -1052     
==========================================
- Hits         2560     1653     -907     
+ Misses        779      634     -145     
Flag Coverage Δ
unittests 72.27% <100.00%> (-4.40%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
echopype/convert/set_groups_azfp.py 98.14% <100.00%> (ø)
echopype/convert/set_groups_base.py 88.04% <100.00%> (-2.07%) ⬇️
echopype/convert/set_groups_ek60.py 91.08% <100.00%> (ø)
echopype/convert/set_groups_ek80.py 94.24% <100.00%> (-1.44%) ⬇️
echopype/convert/convert.py 60.00% <0.00%> (-40.00%) ⬇️
echopype/convert/api.py 80.83% <0.00%> (-5.00%) ⬇️
echopype/convert/utils/ek_raw_parsers.py 54.74% <0.00%> (-0.17%) ⬇️
echopype/preprocess/api.py
... and 21 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4c77300...9ccdf36. Read the comment docs.

@leewujung
Copy link
Member

Thanks @emiliom, this looks great!

One thing I thought of when going through this is that DEFAULT_BEAM_COORD_ATTRS should probably live somewhere else, something like core.py but for convention side of things. Perhaps that's something to be resolved in a more top-down form, related to the pydantic work. For now it seems fine for that to live under set_group_base.py.

On an unrelated note, I noticed that DEFAULT_CHUNK_SIZE is only used for encoding EK60 data. Properly chunking is arguably going to be more important for EK80. I'll submit an issue about that so that we don't forget about that when we get to working on performance-related issues..

@emiliom
Copy link
Collaborator Author

emiliom commented Nov 8, 2021

On an unrelated note, I noticed that DEFAULT_CHUNK_SIZE is only used for encoding EK60 data. Properly chunking is arguably going to be more important for EK80. I'll submit an issue about that so that we don't forget about that when we get to working on performance-related issues..

Continuing the unrelated note, I think I noticed that DEFAULT_CHUNK_SIZE is actually declared in two different modules, the same way, But yeah, that's for another issue

@emiliom
Copy link
Collaborator Author

emiliom commented Nov 8, 2021

One thing I thought of when going through this is that DEFAULT_BEAM_COORD_ATTRS should probably live somewhere else, something like core.py but for convention side of things. Perhaps that's something to be resolved in a more top-down form, related to the pydantic work. For now it seems fine for that to live under set_group_base.py.

Let's revisit that thought for sure, once we're creating the convention-compliance architecture for 0.6.0

@emiliom
Copy link
Collaborator Author

emiliom commented Nov 8, 2021

Thanks for the review. I'll self merge now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants