search

aodn / imos-toolbox

Graphical tool for QC'ing and NetCDF'ing oceanographic datasets
GNU General Public License v3.0
46 stars 31 forks source link

does IMOS read AD2CP bottom-track incorrectly? #791

Closed dankelley closed 1 year ago

dankelley commented 2 years ago

Introduction

I have been working to add support for AD2CP data to the "oce" package in the R language. I am not sure I am reading bottom-track data correctly (see e.g. https://github.com/dankelley/oce/issues/1982), and a websearch turned up the IMOS package. Although I am not a matlab user anymore, I think I can understand your code, and I think there may be an error in it.

Possible IMOS Error

At https://github.com/aodn/imos-toolbox/blob/e19c8c604cd062a7212cdedafe11436209336ba5/Parser/readAD2CPBinary.m#L558 I see that ambiguity velocity is being read as a two-byte (unint16) value. However, my understanding is that it ought to be 4 bytes for bottom-track data (in contrast to other data types, which are 2 bytes). If I am correct in my interpretation, then velocity, etc. may be inferred incorrectly by IMOS (see e.g. https://github.com/aodn/imos-toolbox/blob/e19c8c604cd062a7212cdedafe11436209336ba5/Parser/readAD2CPBinary.m#L569 for the offset used for velocity), and that is why I am writing today. Hopefully, I am wrong, or at least if I'm right, perhaps this can lead to an adjustment to the IMOS code.

My sources for the 4-byte nature of ambiguity-velocity (for bottom-track, not other types) are as follows.

  1. Page 61 of Nortek (2017), as shown in the first snapshot below.

  2. Page 94 of Nortek (2022), as shown in the second snapshot below.

References

Snapshot 1 (2017 manual)

N2017

Snapshot 2 (2022 manual)

N2022
kereid commented 2 years ago

Hi @dankelley thank you for lodging your issue, and please note it has been forwarded on to the appropriate staff to investigate. once they have had a chance to look at it we will get back to you. Warm regards, Kate

lbesnard commented 1 year ago

@dankelley Thanks a lot for your feedback, I've been taking over the maintenance of the toolbox, unfortunately I don't have access to a signature file with bottom tracking to do some testing. Any chance you could upload one? cheers

dankelley commented 1 year ago

@lbesnard sorry, I don't have one I can share.

Almost all the datasets I use in oce development come from users, who wish that they remain private until publication is complete. In lots of cases, the data are being used in thesis work, which makes the timescale long. I imagine IMOS is similar in this respect.

In an ideal world, instrument manufacturers would provide sample datasets (and even perhaps plots of their data) but I guess that's not our world, for most manufactureres.

richardsc commented 1 year ago

Actually @dankelley, I think that we do have a file with bottom track. Note, that this was a bench test, so the data are completely meaningless, but the data structures should be in there.

S102791A002_Barrow_v2.ad2cp.zip

I feel like I have had an example file from Nortek that used bottom track ... at least, an example of using the bottom track to do ice tracking. I'll see if I can find that, or alternatively I might ping Nortek support to send it along again.

lbesnard commented 1 year ago

thanks @richardsc for the test file. I just put a PR to fix this https://github.com/aodn/imos-toolbox/pull/794/files

from my understanding, we've never had bottom tracking files within IMOS, so the parser was probably a work in progress and actually never got used.

lbesnard commented 1 year ago

@richardsc Do you mind if I include your test file in our unittest?

richardsc commented 1 year ago

Not at all! It's just a bench test so the data is completely meaningless, but at least the data structures are there.

evacougnon commented 1 year ago

closing, fix is here: https://github.com/aodn/imos-toolbox/pull/794