Some useful correspondance with Jules Hummon (UH)

Note

Below are some snippets from correspondence with SADCP experts Jules Hummon and Eric Firing. Included here in case they are useful.

(Edited for the purpose by ØF).

Heading streams and “gyro” in VmDAS

Q: I don’t completely understand the data streams here - what goes into N2R and N3R, etc. The documentation seems to indicate that gyro is ideal for primary heading. I tried using an available option |synchro,hdg|, which I thought would be the gyro, but that gave me what looked like pure noise in the heading.

A: Yes, in VmDAS land they call that “gyro” and it is misleading. There is an internal spot in the raw data for heading, and on much older systems, a feed from a synchro converter (? now I’m forgetting, because it was before my time) could be put directly into the back of the deck unit with special cable, and that would get injected into the data stream. But that hasn’t been done for eons. It’s just that since the puka is present in the raw data, and it might contain something useful, I brought it out for use.

It’s not completely stupid: the same data format is used for raw lowered ADCP as for shipboard, and on a lowered instrument there would be a magnetic compass, and that would go straight into the raw data.

Large vertical velocities

Q: After editing, the horizontal velocities look sensible to me. However, the vertical velocities look weird - and I think mostly so during steaming (see panel 6 in the attached figure). I seem to pretty consistently get >10 cm/s downward vertical velocity in the top of the profile when steaming. Does this have anything to do with my settings? And if there are spurious vertical velocities, does that mean that I have artificially /reduced/ the amplitude of the horizontal current components? I understand that vertical velocity isn’t really part of the end product, but I am unsure whether it is a bad sign if the vertical velocity is biased.

A: Some day we’ll make a ‘fix’ for the mean pitch that is causing the large vertical velocities, but the effect is small and at present we are ignoring it. You can ignore it too. :)

Water track

Q I don’t fully understand this, but I have used quick_adcp.py --steps2rerun calib:navsteps --auto to obtain a calibration (catwt.py) and then applied it (quick_adcp.py --steps2rerun rotate:apply_edit:navsteps:calib --rotate_amplitude 1.013 --rotate_angle -0.18 --auto in this case). Calibration made small adjustments but gave notable improvements (yay, I think).

A That’s the 1.013 which is making the difference, and yes, it would be visible. That’s on the large side. In fact if the data have artifacts (shallow underway bias in the direction of travel) that should be edited out before calibrating, and maybe move the reference layer deeper

Defaults:

 rl_startbin = 2              # first bin for reference layer: 1-nbins
 rl_endbin = 20               # last bin for reference layer : 1-nbins

You could use:

--rl_startbin 4  --rl_endbin 10

Bottom tracking

Q Bottom tracking was not enabled, and catbt.py does not exist. Would bottom tracking have been included in the CODAS processing if it had been enabled?

A: yes

Q (Also: Should we enable bottom tracking when on the shelf?)

A: Not needed, not if you have a seapath and the seapath is working. At present and in general, it is working.

But if you do enable BT, make sure you’re only running with one ping type. Our setup is using NB mode only, so enabling BT for a couple of hours once on each cruise won’t hurt anything and it will make you feel better.

Q Also, in the final dataset, the retained data from ice mostly consists of data where the ship is stationary (on station in the ice). Can it be a problem for the water tracking that there is almost no data while the ship is moving for a period of weeks? Or does it just mean that the risk of cross-track biases go away?

It’s true that there’s no watertrack calibration if you only have the on-station data, but (1) if you are using the seapath for heading, watertrack just tells you the remaining transducer alignment offset, and it should be within 0.1deg or 0.2deg for many cruises in a row. (2) When the ship isn’t moving, the errors all shrink

Data in ice

Q: I have run through the standard CODAS-from-VMDAS procedure described in the documentation (as best as I could). From what I can tell, the SADCP data from transit in ice looks consistently bad, and I removed all of it during manual editing (and with relatively strict thresholds; PG>80 and Errvel<500) . The only way I can imagine getting good data from ice is to do heavy single-ping editing before averaging to remove jittery pings but retain pings from when the ship is not actively ramming through ice (which should be some sizeable fraction of the time, I suppose). Is this possible? Or are there other ways? You mentioned that there is /an algorithm that can be applied in postprocessing that will clean it up significantly, likely making quite a bit of the data useful. What is this algorithm? Is it part of the CODAS suite?

A: Yes.

Before you edit, make a copy of your processing directory and call it (eg) os75nb.uvship, and then go in there and run this:

quick_adcp.py --steps2rerun navsteps:calib --refuv_source uvship --auto

and for all steps after, in that directory, include “–refuv_source uvship “ when you run quick_adcp.py.

Explanation here

Sampling configuration in the central Arctic Ocean*

Q: The AO basins is an environment with very low scatterer density and very low background signal. Should we use BB instead of NB to maximise accuracy, or tune anything else in the setup for cruises to the Central Arctic?

A Don’t use BB mode.

A from Eric F:

Other than sticking with NB, I think about the only thing you can do to possibly increase range and PG is to use a longer transmit pulse than you would otherwise.