OSOceanAcoustics / echopype

Enabling interoperability and scalability in ocean sonar data analysis
https://echopype.readthedocs.io/
Apache License 2.0
89 stars 70 forks source link

Fix Duck Array `RuntimeWarning` for EK60 `ep.open_raw` #1337

Closed ctuguinay closed 6 days ago

ctuguinay commented 2 weeks ago

Addresses #1335. I have a step-by-step explanation of the problem and my proposed solution on the linked issue.

codecov-commenter commented 2 weeks ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 77.97%. Comparing base (9f56124) to head (41f987e). Report is 55 commits behind head on main.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #1337 +/- ## ========================================== - Coverage 83.52% 77.97% -5.55% ========================================== Files 64 16 -48 Lines 5686 2624 -3062 ========================================== - Hits 4749 2046 -2703 + Misses 937 578 -359 ``` | [Flag](https://app.codecov.io/gh/OSOceanAcoustics/echopype/pull/1337/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=OSOceanAcoustics) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/OSOceanAcoustics/echopype/pull/1337/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=OSOceanAcoustics) | `77.97% <100.00%> (-5.55%)` | :arrow_down: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=OSOceanAcoustics#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

ctuguinay commented 2 weeks ago

@leewujung This is ready for review. Small fix for a warning I kept encountering when trying to do the OOI notebook PR

ctuguinay commented 1 week ago

@leewujung I made the change that you proposed in #1335. The failing tests are unrelated to this PR and are the processing level tests mentioned in #1342.

I am curious though, why in

EXPECTED_VAR_DTYPE = {
    "channel": np.str_,
    "cal_channel_id": np.str_,
    "beam": np.str_,
    "channel_mode": np.float16,
    "beam_stabilisation": np.byte,
    "non_quantitative_processing": np.int16,
}  # channel name  # beam name

are we only checking for these subset of variable types? Are they special in some way?

leewujung commented 1 week ago

are we only checking for these subset of variable types? Are they special in some way?

In fact I don't remember exactly why. But I think it was due to similar warnings, since before these types were either not set or set to something that would cause a warning.

I think we should at some point implement a pydantic approach for all the types, to avoid the messiness and the arbitrary patching approach you pointed out here.

Also note that our NaN-padding approach probably made many of the resultant types different from those written in the convention. Something we should also discuss, probably with the user community and convention folks.