Aquadopp by jmcvey3 · Pull Request #434 · MHKiT-Software/MHKiT-Python

jmcvey3 · 2026-02-06T00:42:34Z

PR to add functionality to read Aquadopp data packets, but this code has only been tested on Aquadopp profilers (not single-point Aquadopps). Note that Aquadopp/AWAC waves functionality has also been added but is untested.

I've done a decent bit of cleanup of the nortek.py code in this PR as well.

The PR also simplifies the code related to the non-cabled ADV's "orientation_down" parameter. (This parameter exists because the z-axis is flipped on the non-cabled version of the ADV). This PR no longer reads the bit set in each burst ping, which is wont to oscillate for an unknown reason, but instead takes the value from the datafile's header. This means that DOLfYN assumes that a non-cabled ADV is not moved after it starts running.
Cabled ADVs, AWACs and Aquadopps also have the "orientation_down" parameter for user information, but it is not needed otherwise.

…attrs

jmcvey3 · 2026-02-06T00:43:24Z

I have not figured out how to properly set the cell size and blanking distance for high resolution (HR) profiles, so tbd on that.

MRCGit-collab · 2026-02-06T07:10:05Z

Hi @jmcvey3 , thanks a lot for the great work. You are a legend! I will pull and test it hopefully next week.

akeeste

Thanks @jmcvey3. This generally looks good to me. Do we need a new test to cover Aquadopp data?

@MRCGit-collab @MogoBRE if you can test this PR with your datasets that would be very helpful!

akeeste · 2026-02-24T20:20:05Z

examples/data/dolfyn/test_data/AWAC_test01.dolfyn.log

These files are now ignored by .gitignore. I suggest we remove this file entirely

Hold that thought - they're needed in test_data, but not the next directory up, where they're generated and not deleted if that test fails.

akeeste · 2026-02-24T20:35:13Z

Tagging #356 for some of the original discussion

jmcvey3 · 2026-02-24T23:50:48Z

Thanks @jmcvey3. This generally looks good to me. Do we need a new test to cover Aquadopp data?

Yes I need to write tests

simmsa · 2026-02-26T17:22:23Z

mhkit/dolfyn/io/nortek_defs.py

        units="1",
    ),
-    "PressureMSB": _VarAtts(
+    "pressure": _VarAtts(


@jmcvey3, is it possible that changing these variable names would break any analysis code downstream for MHKiT users? IDK if it is worth having some deprecation strategy here or what makes sense. This could quickly get complex and difficult, but curious how you handle changes here more than anything.

For the ones I changed here, no, since they don't actually show up on the user side. I did a lot of "standardizing" of this nortek code to make it consistent with the rest of dolfyn; the line you highlighted here set up the pressure variable differently than everywhere else in dolfyn.

Sounds good, thanks for the clarification.

simmsa · 2026-02-26T17:29:35Z

mhkit/dolfyn/io/nortek_defs.py

+        default_val=nan,
+        units="1",
+        long_name="Acoustic Signal Amplitude",
+        standard_name="signal_intensity_from_multibeam_acoustic_doppler_velocity_sensor_in_sea_water",


@jmcvey3 I think that adding standard names from the CF standard names table is a nice addition here. Do you think including the description would also be valuable?

Also, one nit here that I don't know how to solve is the sea_water part of the cf convention names. I think there are likely situations where the instrument is deployed in NOT sea water and that standard name may be incorrect and misleading. I don't have an obvious solution, just more of an observation here. I don't other non sea water variants signal_intensity_* in the cf standard name table.

Yeah I don't have a good answer for you here since CF standard names doesn't do ADCP variables well. I've been tempted to leave these standard names off completely.

Adding a description makes it even more dependent on context - this is what Tsdat is useful for.

IMO, the CF standard names are a step in the right direction vs not specifying a "name". standard_name works well in xarray and other netcdf tooling, but here specifically it is not "flexible" enough and may lead to confusion by the end user.

Does it "break" the cf standard or nc files in general if MHKiT uses standard_names that are not in the table?

If the standard_name does not need to perfectly match could we just remove sea_ here, so it becomes: signal_intensity_from_multibeam_acoustic_doppler_velocity_sensor_in_water.

Or alternatively have the user input fresh or sea water or something (also we would have to make the user choose or figure out this setting from data, which seems doable, but likely not necessary)? That could get messy with areas with both/mixing so maybe just water is fine?

Also if the simple solution is removal of standard_name for this situation, that seems reasonable here also.

No, creating your own standard name defeats the purpose of standard names. If anything, the user is ultimately responsible to add enough metadata to their data so that others can understand it properly. We can't cover every edge case.

@jmcvey3 Understood. I can appreciate the rigidity of the CF conventions, and appreciate the guidance here. CF Standards are something that I'm still working to understand fully.

Because we can't guarantee that an acoustic instrument is deployed in sea_water it seems like we should remove the standard_name here, or make including the standard_name an option somehow?

ME Data Pipeline Standards Version 1.0 has some guidance also:

Based the above description, the standard_name is "not required" because a suitable standard name for this variable does not exist? Do you agree with that?

I don't have a hard opinion on this. We can remove it if you'd like

It seems wise to remove just in case a deployment is in fresh water.

So I am in favor of removing.

Well, I take it back, I've developed an opinion - every single standard_name includes "sea_water". I think this goes beyond the scope of this PR

If there are other sea_water related changes that you would want to make, then yes that is outside of the scope of this PR.

What do you want to do for this instance?

I realize that this is a bit "in the weeds" also. I'm in favor of getting the functionality of this merged and focusing on metadata at some later time.

MRCGit-collab · 2026-03-04T13:13:47Z

Hi all, Apologies for not replying earlier. I have been inundated with other work and lost track of this. I pulled the PR and tried running it on my data set. I get a consistent error message: self._inst = self.config.pop("config_type") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ KeyError: 'config_type' I'm no advanced user (and more of a field tech) and I checked with a few people but we couldn't figure out the issue. So please excuse if this is a simple fix and a fault on my side. I will continue to work on it, if I have time (it's still part of an ongoing project). THanks in advance for all the effort! Cheers, Jürgen Zier Marine Robotics Centre - MRC T +32 (0)59-336229 / M +32 (0)468-293395

…

________________________________ From: Adam Keester ***@***.***> Sent: Tuesday, 24 February 2026 21:35 To: MHKiT-Software/MHKiT-Python ***@***.***> Cc: Juergen Zier ***@***.***>; Mention ***@***.***> Subject: Re: [MHKiT-Software/MHKiT-Python] Aquadopp (PR #434) @akeeste approved this pull request. Thanks @jmcvey3<https://github.com/jmcvey3>. This generally looks good to me. Do we need a new test to cover Aquadopp data? @MRCGit-collab<https://github.com/MRCGit-collab> @MogoBRE<https://github.com/MogoBRE> if you can test this PR with your datasets that would be very helpful!

________________________________ On examples/data/dolfyn/test_data/AWAC_test01.dolfyn.log<#434 (comment)>: These files are now ignored by .gitignore. I suggest we remove this file entirely — Reply to this email directly, view it on GitHub<#434 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B5PB4DDWH63A2CODCNCDYA34NSYXPAVCNFSM6AAAAACUFILMHGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTQNJQGMYTMNJSG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

MRCGit-collab · 2026-03-04T14:38:56Z

Hi James, Just a quick update, issue was on my side, I managed to run it and looks ok at first sight. Will do some further testing and give you an update. Thanks a lot. Juergen Jürgen Zier Marine Robotics Centre - MRC T +32 (0)59-336229 / M +32 (0)468-293395

…

________________________________ From: Juergen Zier ***@***.***> Sent: Wednesday, 4 March 2026 14:13 To: MHKiT-Software/MHKiT-Python ***@***.***>; MHKiT-Software/MHKiT-Python ***@***.***> Cc: Mention ***@***.***> Subject: Re: [MHKiT-Software/MHKiT-Python] Aquadopp (PR #434) Hi all, Apologies for not replying earlier. I have been inundated with other work and lost track of this. I pulled the PR and tried running it on my data set. I get a consistent error message: self._inst = self.config.pop("config_type") ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ KeyError: 'config_type' I'm no advanced user (and more of a field tech) and I checked with a few people but we couldn't figure out the issue. So please excuse if this is a simple fix and a fault on my side. I will continue to work on it, if I have time (it's still part of an ongoing project). THanks in advance for all the effort! Cheers, Jürgen Zier Marine Robotics Centre - MRC T +32 (0)59-336229 / M +32 (0)468-293395

________________________________ From: Adam Keester ***@***.***> Sent: Tuesday, 24 February 2026 21:35 To: MHKiT-Software/MHKiT-Python ***@***.***> Cc: Juergen Zier ***@***.***>; Mention ***@***.***> Subject: Re: [MHKiT-Software/MHKiT-Python] Aquadopp (PR #434) @akeeste approved this pull request. Thanks @jmcvey3<https://github.com/jmcvey3>. This generally looks good to me. Do we need a new test to cover Aquadopp data? @MRCGit-collab<https://github.com/MRCGit-collab> @MogoBRE<https://github.com/MogoBRE> if you can test this PR with your datasets that would be very helpful!

________________________________ On examples/data/dolfyn/test_data/AWAC_test01.dolfyn.log<#434 (comment)>: These files are now ignored by .gitignore. I suggest we remove this file entirely — Reply to this email directly, view it on GitHub<#434 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B5PB4DDWH63A2CODCNCDYA34NSYXPAVCNFSM6AAAAACUFILMHGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTQNJQGMYTMNJSG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

jmcvey3 added 7 commits December 13, 2024 17:07

Add initial commit for aquadopp profiler

3f181e9

Add other aquadopp specific structures

ea18423

Merge branch 'develop' into aquadopp

dc96f05

Major progress on aquadopp

c207a16

Fix orientation_down attr, nortek code cleanup

0f522d7

Update test data to remove orientation_down variable and update AWAC …

afc48a2

…attrs

Black formatting

868985c

jmcvey3 added 3 commits February 6, 2026 11:55

Correct comments, guestimate HR cell size and blank coefficients

54da94a

Update cell size and blank distance calculations

633add5

Code cleanup and standardization

d0cd1e6

jmcvey3 added the dolfyn module label Feb 10, 2026

jmcvey3 requested review from akeeste and simmsa February 19, 2026 17:38

akeeste approved these changes Feb 24, 2026

View reviewed changes

jmcvey3 added 3 commits February 25, 2026 16:50

Add Aquadopp profiler tests

59b5647

Merge branch 'develop' into aquadopp

49f7c59

Update gitignore

2c2e6bd

simmsa reviewed Feb 26, 2026

View reviewed changes

jmcvey3 merged commit 922b270 into MHKiT-Software:develop Mar 17, 2026
40 of 58 checks passed

jmcvey3 deleted the aquadopp branch March 17, 2026 16:44

Conversation

jmcvey3 commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jmcvey3 commented Feb 6, 2026

Uh oh!

MRCGit-collab commented Feb 6, 2026

Uh oh!

akeeste left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akeeste commented Feb 24, 2026

Uh oh!

jmcvey3 commented Feb 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simmsa Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MRCGit-collab commented Mar 4, 2026 via email

Uh oh!

MRCGit-collab commented Mar 4, 2026 via email

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jmcvey3 commented Feb 6, 2026 •

edited

Loading

simmsa Feb 26, 2026 •

edited

Loading