Preliminary report on HLY-03-03 ADCP data collection

Andreas Münchow, Graduate College of Marine Studies, University of Delaware

Oct. 17, 2003

1. Introduction

The USCGC Healy contains two separate and independent hull-mounted acoustic Doppler current profiler systems. The systems are a 75 kHz phased array (Ocean Surveyor) and a regular 4-beam 153 kHz transducer (BroadBand). Each system is mounted in its own well that is filled with anti-freeze solution and is separated from the water by an acoustic window. The 75 kHz system performed exceptionally well during HLY-03-03 without ANY of the problems reported in prior years (see Flagg’s, 2002 SBI-ADCP report) or even this year (see Münchow’s 2003 CATS-ADCP report on HLY-03-01). The system is fully operational and requires minimal operator interference if it is setup and maintained correctly. The same cannot be said for the 153 kHz system which is not operational at the present time. Excessive mechanical and/or electromagnetic noise reduced both water tracking range and data quality below acceptable levels. When I noticed it to interfere with the OS-75 system, I stopped data collection entirely in order to not to compromise the functioning OS-75 system. This report refers to the 75 kHz system only. I will prepare a separate report on the 153 kHz BroadBand system before the end of Oct. 2003.

2. Data streams

The 75 kHz Ocean Surveyor (OS75) was run via VMDAS under Windows-2000 Professional and controls input and output data streams. VMDAS receives

OS75 single ping data via serial port COM7 (.ENR file on output),

Gyro heading data via serial port COM7 (.ENR file on output),

P-code (aft) GPS data via serial port COM8 (.N1R file on output), and

Ashtech navigational and attitude data via serial port COM9 (.N2R file on output)

The aft P-code GPS system is distinct from the bridge P-code GPS system. VMDAS generates 10 different output files that merge and average data from the three input streams in varying ways. A .LOG file contains both direct commands send to the OS75 on start-up as well as all subsequent error messages. The most frequent, very intermittent error messages were

[date,time]: NMEA [RPH] communication time out

[date,time]: NMEA [RPH] Error writing to raw data file

indicating that VMDAS does not receive the Ashtech data. Generally, the Ashtech dropped out intermittently for a few minutes every day. Prior data recording problems were eliminated entirely when all data were recorded on the local machine ONLY. As backup, the science data network copies updated files from that local drive to its F: drive without interference of VMDAS. Hence the recommendation from HLY-03-01 that “…A single, stripped down, stand-alone CPU with dedicated serial inputs may remedy many ADCP data collection. The ADCP data collection CPU should NOT be used for ANY other processes besides data collection…” resulted in a clean, uninterrupted ADCP data stream of the highest quality.

3. Performance

The OS75 performed extremely well during the cruise when run NarrowBand mode using 15-m vertical bins and 10-m blanking. The water profiling range hovered around 400-450 m depending on the presence of scatters in the water column (Figs. 1 and 2). The OS75 tracked the bottom without any problems down to 900-1100-m. Ship speeds below 15 kts had little effect on the systems performance and an optimum ship speed in waters may be 12-14 kts.

A careful misalignment calibration routine following Joyce (1989) in the vertical planes is needed to accurately determine the deviation of the instrument from its nominal 30 degree vertical beam angle. More specifically, I find that a misalignment calibration is necessary in the (x,y) and the (x,z) and the (y,z) planes for which I derived the following coefficients:

(x,y)-plane: alpha-1=-44.1 degrees and beta-1=1.00316

(x,z)-plane: alpha-2=+0.94 degrees and beta-2=1.0 (this accounts for a mean roll and/or trim and/or x-ducer face not level and/or ...

(y,z)-plane: alpha-3=-0.90 degrees and beta-3=1.0 (as above, but for mean pitch ...)

In order to derive these coefficients, I am using only Ashtech headings and aft P-code GPS systems for about 2 weeks continueous ADCP profiling with bottom track. The data so calibrated makes it hard to distinguishable between GPS-derived and ADCP-derived vessel speeds. Hence I decided to turn off the bottom-track about half way through the cruise in order to ping the water twice as fast giving me twice the horizontal.

A potentially troublesome discovery during HLY-03-03 was a large and systematic discrepancy of underway and on-station data over the top 50-60 m of the water column in both vertical and horizontal velocities reaching about 10 cm/s (Figs. 3-5. The source of this underway bias is still unclear, however, the ADCP data collected during HLY-03-03 will need to be scrutinized carefully for this effect that must be (a) understood and (b) removed/calibrated out in post-processing in order to obtain a data set suitable for dynamical analyses of surface waters in addition to those deeper in the water column.

4. Data processing and sharing

I processed the .ENS, .ENR, .N1R, and .N2R single ping data streams in real time using University of Delaware software specifically written and designed for the 2003 missions of the USCGC Healy utilizing the science data network as most efficient means to transfer large data from the ship’s computer system to a Mac Powerbook G4 and posting processed ASCII data, maps, and charts on the public drive for all members of the science crew. In addition hard copies of sections, maps, and time series were provided to the Chief Scientist on both a daily and as-needed basis.

It should be understood that all posted data, products, and analyses are very raw, very preliminary and should not be distributed to the SBI or wider science community as they have not yet fully scrutinized by the SBI-ADCP Service group (Flagg, Münchow, and Padman). I expect that the ADCP-Service group will release an official, calibrated, screened, and fully quality-controlled version of the HLY-03-03 OS-75 ADCP data set at the Dec. 2003 SBI-PI meeting in Seattle.

The exceptionally light ice year, a well-calibrated instrument, and detailed real-time analyses resulted in much excitement and discussions on evolving flow and hydrographic features both over the slope of the Beaufort (Figs 1 and 2) and the Chukchi (Fig. 6) Seas among the scientists aboard. The separation of SBI “science PIs” and “service PIs” caused initial friction, conflict, and discomfort. The exceptionally small, personal, and mostly physical science group facilitated open communication and data sharing that are more difficult to archive in larger, disciplinary more diverse science groups. The SBI “science” vs. “service” model thus has the potential to severely undermine science, collegiality, and peer review that are all core values of the NSF.

The following Ocean Science Meeting (Portland) abstract perhaps documents our success to overcome the science vs. service separation (Figs. 1 and 2):

Evolution of a “Poleward Undercurrent” over the continental slope off Arctic Alaska; Andreas Münchow, Robert Pickart, and Rebecca Woodgate

The term “poleward undercurrent” refers to flows over continental slopes that are subsurface, in the direction of Kelvin wave propagation, and oppose the wind. Although such flows are generally observed in Eastern Boundary Current regions such as off California, Peru, and North-West Africa, we find all these ingredients in the Arctic Beaufort Sea off northern Alaska in the fall 2003 when we surveyed the velocity field along a 60-km section for 2 weeks with the 75 kHz Ocean Surveyor ADCP aboard the USCGC Healy. We hypothesize that the Arctic Ocean circulation, which is dominated by flows along topographic slopes, bears dynamical similarity to Eastern Boundary Currents.

Two Aleutian low-pressure systems resulted in sustained upwelling favorable (easterly) winds reaching 50 kts. The shelf circulation responded within an inertial period to this forcing with a barotropic current exceeding 0.5 m/s. Most dramatic, however, was the slower evolution of a bottom-intensified 0.3 m/s strong, 15-km wide, eastward flow along the upper continental slope between the 100-m and 300-m isobaths that opposed the local winds. Its seaward extent coincided with the inshore edge of a surface-intensified jet. Substantial across-slope flows also occurred; however, it is difficult to define an across-slope direction in the presence of a rugged bottom. Rossby numbers of both bottom- and surface intensified flows were about 0.4 suggesting that nonlinear inertial terms contribute to the dynamics in addition to topographic beta-effects.

5. Watchstanders

No watchstanders were available or required. The 3-hourly rounds by the ship’s MSTs are sufficient to maintain the system, however, all MSTs and the scientific community would benefit if the Healy MSTs were required to attend the annual ADCP training courses offered by RD Inc. in San Diego. It would give them confidence and experience to monitor and operate a complex scientific instrument using “independent thinking” rather than rigid memorization” skills. These skills will transfer well to other sonar devices aboard the ship. I recommend the RDI training course in the strongest possible terms. My own technician David Huntley went through this training, he is full of praise for it, and most supervised ADCP operations on HLY-03-Td as a Coast Guard contractor.

6. Recommendations

The science data network requires a level-2 system administrator. I feel most strongly that the MSTs should NOT be given the additional responsibility to administer a complex science data and computer network. They are mostly level-1 support (the point-and-click kind) while Joe DiGiovanni is a level-2 support who traces down a problem at the system level by writing and modifying scripts that run the computer network. He is a temporary Coast Guard hire/contractor unlikely to be available next year. The lack of continuity in managing and running the science data and computer networks constitutes a major problem.

RDI Training Courses. All Healy MSTs should be required to pass a week-long training ADCP course offered several times each year by RDI in San Diego. This will benefit future underway ADCP operations, ADCP mooring recovery and deployment operations, and lowered ADCP operations that all require independent thinking skills.

Monitor file size and content of .LOG files. The .LOG files contain the initial set-up of the ADCP and all subsequent error messages. Ideally, it’s size is less than 4KB. The rapid increase indicates that some component of the ADCP data collection system is not functioning. Review all .LOG files that become larger than, say, 10K to track down and problem solve.

Provide averaged SeaBeam data. The ADCP can send both bottom and water tracking pings, however, the ship’s Aft-Pcode GPS system can provide very accurate estimates of the ship’s velocity such that the bottom tracking ping may be substituted for an additional water tracking ping. The absence of a bottom tracking ping, however, requires that a substitute and reliable data stream for bottom depth can be found. The SeaBeam Centerbeam often appears unreliable as neigboring beams report bottom depth but the centerbeam does not. ADCP processing could benefit from some aggregate or average bottom depth accurate to within 4-m.

Merge thermosalinograph and wind data streams with Pcode GPS position data.

Remove personal computer video gaming from the Future Lab. The involved gaming of groups of young crew members disturbs the work environment in the Future Lab.

7. List of files

All file names start with HLY-03-03osxxx_yyyyyy.zzz where xxx or xxxxx are numerical file designation for a single configuration that may consist of yyyyyy separate files, and zzz is the file extension, e.g., ENR for single-ping raw, N1R for P-code GPS, and N2R for Ashtech GPS data. All times are UTC, longitudes are in decimal degrees West, and latitudes are in decimal degrees North.

Start of file End of file

file #pings | start time, date,lat,lon | end time, date, lat,lon | hrs

os001 25 | -2.6 911 21:26 71.30 156.98 | -2.5 911 21:29 71.30 156.97 | 0.1

os002 2268 | -2.5 911 21:31 71.31 156.97 | 0.4 912 0:21 71.44 156.95 | 2.8

os003 4944 | 0.5 912 0:31 71.44 156.95 | 5.5 912 5:32 71.37 157.19 | 5.0

os004 694 | 5.6 912 5:33 71.37 157.19 | 5.9 912 5:56 71.39 157.17 | 0.4

os005 19773 | 5.9 912 5:57 71.39 157.17 | 22.4 912 22:26 71.24 159.84 | 16.5

os006 23302 | 22.5 912 22:29 71.24 159.83 | 41.9 913 17:54 71.25 157.78 | 19.4

os007 32683 | 41.9 913 17:55 71.25 157.78 | 69.1 914 21:09 70.94 159.30 | 27.2

os008 67 | 69.2 914 21:12 70.94 159.31 | 69.3 914 21:19 70.96 159.34 | 0.1

os009 1 | 69.3 914 21:20 70.96 159.34 | 69.3 914 21:20 70.96 159.34 | 0.0

os010 350 | 69.4 914 21:22 70.97 159.36 | 69.7 914 21:41 71.02 159.47 | 0.3

os011 275 | 69.7 914 21:43 71.03 159.47 | 70.0 914 21:58 71.05 159.51 | 0.2

os012 15431 | 70.1 914 22:03 71.05 159.51 | 85.6 915 13:33 0.00 0.00 | 15.5

os013 19826 | 85.8 915 13:46 73.08 164.85 | 103.5 916 7:30 73.17 166.28 | 17.7

os014 39 | 103.6 916 7:34 73.17 166.29 | 103.6 916 7:36 73.16 166.31 | 0.0

os015 14474 | 103.6 916 7:37 73.16 166.32 | 116.7 916 20:41 73.75 167.96 | 13.1

os016 3891 | 117.2 916 21:11 73.75 167.96 | 121.5 917 1:30 73.93 168.17 | 4.3

os017 1744 | 121.5 917 1:31 73.93 168.17 | 122.5 917 2:29 73.86 167.92 | 1.0

os018 116 | 122.5 917 2:30 73.86 167.92 | 122.6 917 2:34 73.86 167.90 | 0.1

os019 13025 | 122.6 917 2:35 73.86 167.89 | 137.1 917 17:03 73.61 166.04 | 14.5

os020 1054 | 137.1 917 17:04 73.61 166.04 | 137.9 917 17:57 73.62 166.05 | 0.9

os021 15009 | 138.0 917 17:58 73.62 166.05 | 147.3 918 3:17 74.07 164.62 | 9.3

os022 10660 | 147.4 918 3:21 74.08 164.60 | 160.6 918 16:39 74.25 165.21 | 13.3

os023 39599 | 160.7 918 16:40 74.25 165.22 | 187.5 919 19:29 72.69 165.99 | 26.8

os024 60551 | 187.5 919 19:29 72.69 165.99 | 221.1 921 5:08 70.82 161.72 | 33.6

os025 76309 | 221.1 921 5:09 70.81 161.72 | 263.6 922 23:33 70.70 165.89 | 42.4

os026 36161 | 263.6 922 23:34 70.70 165.88 | 283.6 923 19:39 71.25 159.53 | 20.1

os027 23727 | 283.7 923 19:40 71.25 159.52 | 303.9 924 15:53 71.52 151.95 | 20.2

os028 803 | 303.9 924 15:54 71.52 151.94 | 305.0 924 17:01 71.67 151.84 | 1.1

os029 3923 | 305.1 924 17:08 71.67 151.84 | 309.8 924 21:50 71.66 151.80 | 4.7

os030 4196 | 309.9 924 21:51 71.66 151.80 | 316.0 925 4:01 71.83 151.67 | 6.2

os031 8974 | 316.0 925 4:01 71.83 151.67 | 326.2 925 14:11 71.57 151.82 | 10.2

os032 654 | 326.2 925 14:12 71.56 151.83 | 327.1 925 15:08 71.54 151.94 | 0.9

os033 23323 | 327.1 925 15:09 71.54 151.94 | 349.4 926 13:22 71.49 151.96 | 22.2

os034 5571 | 349.4 926 13:23 71.49 151.97 | 353.9 926 17:54 71.52 151.99 | 4.5

os035 28148 | 354.0 926 17:58 71.53 151.99 | 380.7 927 20:42 71.39 152.03 | 26.7

os036 5158 | 380.7 927 20:43 71.39 152.04 | 384.6 928 0:33 71.50 151.94 | 3.8

os037 45171 | 384.6 928 0:33 71.50 151.94 | 428.0 929 19:58 71.84 151.69 | 43.4

os038 90319 | 428.0 929 20:02 71.84 151.69 | 478.2 1001 22:13 71.66 152.80 | 50.2

os039 4980 | 478.2 1001 22:13 71.65 152.80 | 482.2 1002 2:13 71.26 152.18 | 4.0

os040 5059 | 482.2 1002 2:13 71.26 152.18 | 486.2 1002 6:14 71.44 152.05 | 4.0

os041 15100 | 486.2 1002 6:15 71.45 152.04 | 501.1 1002 21:03 71.67 151.85 | 14.8

os042 25119 | 501.4 1002 21:26 71.66 151.82 | 515.4 1003 11:24 71.33 152.12 | 14.0

os043 2221 | 515.4 1003 11:24 71.33 152.12 | 516.3 1003 12:17 71.39 152.06 | 0.9

os044 75007 | 516.3 1003 12:18 71.40 152.06 | 558.0 1005 5:58 71.69 152.55 | 41.7

os045 18641 | 558.0 1005 6:01 71.70 152.55 | 568.4 1005 16:23 71.30 152.13 | 10.4

os046 134 | 568.4 1005 16:25 71.31 152.13 | 568.5 1005 16:28 71.31 152.14 | 0.0

os047 86058 | 568.5 1005 16:29 71.31 152.14 | 624.4 1008 0:21 71.42 152.08 | 55.9

os048 18369 | 624.4 1008 0:22 71.42 152.08 | 636.7 1008 12:42 71.44 152.02 | 12.3

os049 82776 | 636.7 1008 12:43 71.44 152.02 | 678.8 1010 6:46 71.94 157.21 | 42.1

os050 48 | 678.8 1010 6:47 71.94 157.22 | 678.8 1010 6:48 71.94 157.23 | 0.0

os051 44855 | 678.8 1010 6:49 71.93 157.24 | 694.1 1010 22:03 71.12 158.25 | 15.2

os052 82286 | 694.1 1010 22:09 71.12 158.26 | 735.9 1012 15:57 72.97 160.73 | 41.8

os053 98214 | 736.0 1012 15:58 72.97 160.73 | 785.9 1014 17:52 73.29 158.36 | 49.9

os054 67211 | 785.9 1014 17:53 73.29 158.36 | 820.0 1016 4:02 72.74 157.45 | 34.2

os055 17898 | 820.1 1016 4:03 72.74 157.45 | 831.2 1016 15:10 72.42 158.50 | 11.1

8. Relevant E-mail communications

8.1 Mid-cruise update to the science community

From: Andreas Muenchow <amuenchow@bkr2.rdc.uscg.gov>

Date: Mon Sep 29, 2003 7:19:51 PM America/Anchorage

To: flagg@bnl.gov

Cc: woodgate@apl.washington.edu, rpickart@whoi.edu, jgrebmei@utk.edu, efiring@hawaii.edu, nswanberg@nsf.gov, DForcucci@d11.uscg.mil, muenchow@udel.edu, padman@esr.org, dforcucci@pacnorwest.uscg.mil

Subject: Healy ADCP update

Hi all,

It's half way through my first SBI cruise and would like to give you a brief update on what is happening with the ADCPs aboard the Healy as we are sitting and steaming across the Beaufort slope between the 50-m and the 2000-m isobath. The OS-75 kHz is working like a charm without ANY of the bugs that have been reported in the past. The buffer overflow "problem" went away when I put the data collection in high priority within Windows in July. The almost twice daily system crash, screen lock-up, data screw-ups, problems with recording some files at some times but not at others at other times went away when I stopped recording to the Data Science Network drive entirely. It took me the better part of 5 weeks (shame on me, but there were other things I had to attend to) in July and August to figure this out as there was no pattern to the madness for the longest period. Hence I conclude that ALL prior problem are software and Microsoft-platform related. The system has been running without any hick-ups for the last 3 weeks since I boarded at Barrow and before that throug the North-West passage when my tech. David Huntley took care of. I reboot the machines every 2-3 days and stop/start data collection once or twice a day. Joe DiGiovanni installed both time synchronizations and non-interfering back-up copies every hour or so in the background to the network. He's an excellent and absolutely essential member of the science support team for system administration. The Coast Guard's Marine Science (or is it Safety?) Technicians have their hands full doing an excellent job running everything else. I feel most strongly that they should not be given the additional responsibility to administer a complex science data and computer network. They are mostly level-1 support (the point-and-click kind) while Joe is a level-2 support who traces down a problem at the system level by writing and modifying scripts that run the computer network. He is a temporary Coast Guard hire/contractor and I hope this year's very positive experience with the science data network becomes the rule rather than the exception.

The lack of data collection problems gives me much needed time to process the data from single-ping binaries to publication-ready sections and vector maps. In order to do so, I wrote substantial software for the NSF-funded Canadian Archipelago Throughflow Study as it affords me the substantial support to do so. It's this software that I am using on my little Mac PowerBook G4. More specifically, I find that a misalignment calibration a la Joyce (1989) is necessary in all three planes, that is, in the (x,y) and the (x,z) and the (y,z) planes for which I am using the following coefficients:

(x,y)-plane: alpha-1=-44.1 degrees and beta-1=1.00316

(x,z)-plane: alpha-2=+0.94 degrees and beta-2=1.0 (this accounts for a mean roll and/or trim and/or x-ducer face not level and/or ...

(y,z)-plane: alpha-3=-0.90 degrees and beta-3=1.0 (as above, but for mean pitch ...)

In order to derive these coefficients, I am using only Ashtech headings and aft P-code GPS systems for about 2 weeks contineous ADCP profiling with bottom track. The data so calibrated looks increadible clean and I can no longer distinguish between GPS-derived and ADCP-derived vessel speeds. Hence I decided to turn off the bottom-track completely in order to ping the water twice as fast giving me twice the horizontal resolution which for a 5-min average with bottom- and water-tracking pings at 10 kts ship speed is about 1.5-km. Oh, I am running 30 NarrowBand vertical bins 15-m deep. The profiling range in Arctic waters hovers about 400-m which I account on the acoustic window and the lack of scatters in the Atlantic layer waters below the halocline that we are fully resolving. There is no data above about 28-m below the surface. The 153-kHz ADCP may help somewhat, but it has serious problems. I do not consider it operational even though I am running it. The "hash" that Jules Hummon reported in 2000 or 2001 now dominates the record, contaminating pings at a contineously changing rate. It's profiling range has furthermore detoriated to no more than 50-m. I will need to write a separate report on this before the end of the month as the ship goes into dry-dock after unloading in Seattle the first week in Nov. I suspect that the transducer plates are not entirely shielded from mechanical ship vibrations that are transmitted to the the bolts holding the transducer plate in place (but why does this not affect the bottom-tracking pulse, BT works fine on the 153 kHz).

There is just one problem that I will need to address and I think I know how even though I do not fully understand its exact cause. Earlier I noticed a rather systematic discrepancy between velocity profiles underway and on station. More specifically, underway the vertical velocity over the top 50-60 m is of the same order as the discrepancy between the on-station and underway horizontal velocity. I am wondering if the ADCP is measuring hull-induced flows. I am bit surprised, though, to see this effect so deep. Rebecca generously profided me with about 4 hours of ship time to run a systematic test pattern over one of Bob Pickard's mooring sites. This, along with a systematic "performance" scan of all ADCP data, will greatly aid to (a) quantify this effect and (b) remove it. Any suggestions on what this might be and if this is seen on other large ships with 9-m draft and 16,000 ton displacement are more than welcome.

All is very well, we're finding 0.8 Sv flows over the slope with Rossby numbers approaching 0.4 :)

andreas

P.S.: I'll process all Arctic (between St. John's and Nome) 2003 Healy ADCP data in the same fashing posting processed and calibrated data prior to the Dec. SBI-PI meeting that I plan to attend.

P.P.S.: Did anyone take care of the ADCP aboard the Palmer? I'd like to get a copy of the single-ping binary and raw navigation files to go with it in order to have a complete copy of the entire 2003 SBI ADCP data set.

Andreas Muenchow http://newark.cms.udel.edu/~muenchow

College of Marine Studies tel: 302-831-0742

University of Delaware fax: 302-831-6838

Newark, DE 19716 amuenchow@bkr2.rdc.uscg.gov

muenchow@udel.edu

8.2 On-station vs. underway data quality (Figs. 3-5)

From: Andreas Muenchow <amuenchow@bkr2.rdc.uscg.gov>

Date: Tue Sep 30, 2003 5:57:58 PM America/Anchorage

To: Jules Hummon <hummon@hawaii.edu>

Cc: flagg@bnl.gov, rwoodgate@sci.uscoastguard.net, efiring@hawaii.edu

Subject: Re: Healy (and Palmer) ADCP

Jules,

No problem to provide you with any Healy data you may find useful and it would be great to have the Healy included in your study. If there is any special parameter range and/or set-up that you would like me to run data for your paper, I'd be delighted to do so. I am on file #39 3 weeks into the cruise for the OS75 and #20 on the BB-153. The OS data are very clean as the Healy is such a stable platform. Dedicated P-code GPS and Ashtech coverage is most excellent right now as well even though I did not like the pitch and roll I got from the Ashtech. The entire system is pretty awsome for someone who has been struggling with magnetic compasses towing ADCPs from ship-of-opportunities.

I pretty much ran bottom track most of time until yesterday as 70% or so of our work is within ~950-m BT range. And yes, we have scattering layers at times at the right (physical) place where one would expect scatters to converge. I also experimented with recording both broadband and narrowband pulses in shallow water (50-m) to play it both safe (8-m NB pulse) and make the best out of a bad/shallow situation (5-m BB pulse). The BB-pulse is a little more fickle, e.g., more drop outs even though I followed all your recommendations in your most useful OS-75 and NB-153 kHz intercomparison paper from an East Coast transit leg.

There is just one problem I have right now besides the BB-153, but that's another story. The OS-75 "problem" relates to a very systematic bias in the vertical profile of vertical velocity w(z) underway as compared with on-station work. I am using this vertical velocity for quality control. Furthermore, the difference between on-station and underway horizontal velocity has a very similar looking profile as w(z) that is close to zero and vertically uniform while on station only. The effect tapers off exponentially (or perhaps linearily, hard to tell) toward 60-m depth (4-5 bins). It would surprise me to see ship's hull effects this deep, so, I am also wondering if the nominal 30 degree beam orientations are (a) off somewhat and/or (b) different for water and bottom tracking pulses. Oh, the vertical velocity in this top layer varies fairly linear with the ship speed reaching 20 cm/s at 16 kts, steady 12 cm/s at 10 kts, and perhaps 8 cm/s at 6 kts. Some scatter, but the the statistics would be tight. Did you see anything similar?

With regard to the Palmer SBI ADCP data, I am funded as part of the SBI-service component to analyze and interpret SBI-ADCP data with 2 graduate students. I like to process all ADCP data from single-ping binaries. I think the Palmer runs a 153 kHz NarrowBand system, so I'd like to work with the raw pingdata and raw navigation files. On the Healy right now I am using only the .ENS, .N2R, and .N1R files with the .ENR for backup. Processing the entire cruise takes less that 10 minutes right now and I redo everthing every few days as I am looking for different things to improve performance and processing. There is no real rush on me getting the Palmer data as I'll be at sea another 3 weeks, however, I did promise to report on the status of SBI-ADCP data at the PI meeting in Dec.

Please let me know what you think and what you may want me to do with regards to your data/performance/intercomparison studies. I could even post data shortly after I colllect them on my web-server back home. Just let me know what you would need and I'd send it to you.

andreas

Andreas Muenchow http://newark.cms.udel.edu/~muenchow

College of Marine Studies tel: 302-831-0742

University of Delaware fax: 302-831-6838

Newark, DE 19716 amuenchow@bkr2.rdc.uscg.gov

muenchow@udel.edu

Separate e-mail, distribution and date unknown

USCGC Healy 0303,

Thank you for your quick responses on the Healy ADCP questions (that I did not get, but Rebecca forwarded me her copy). The attached 4 postscript files perhaps help to visualize the underway vertical/horizontal velocity bias. I don't think it's ringing, the blanking is 10-m and I generally see the same Pg in the top bin as I do anywhere else in the profile. I have seen the usual ship-mounted bias in the vertical velocity on coastal research vessels and towed systems, but that effect never extended as deep into the water as the 50-60 m on the Healy, but I may not have looked as closely at the older data as I have at the Healy data the last 2 weeks. The vertical extend surprises me as does the apparent correlation with the horizontal velocity profile.

To complicate matters further, a change in the ship's steaming direction does not change the bias, however, it distributes it differently among horizontal components. I know that I can "calibrate" it out with three rotations similar to what I did with the BT. More specifically, the scatter plot of water track vertical velocity vs. ship speed looks very similar (and linear) to the bottom-track vertical velocity vs. ship speed. Since I do not understand beam-forming, is it possible that the "nominal beam angles" from the phased-array are different for BT and WT pings? If this were so, why would this cause vertical variations? Do you know of some ADCP/phased-array reference that I could read up on? I have your and Jules paper on the Endevour and have a 2003 JTech paper by some Germans. Perhaps Jerome Smith at Scripps may have an idea ...

The enclosed plots are different perspectives if the same data we took along a straight 12-hrs section across the shelf break with a regular on-station/underway cycle. All data are calibrated as best as I can right now and use bottom track for reference. The 5-min. averages are averaged separately into on-station and underway 12 hour averages. This, I believe, reduces about 80% of the tidal variance (mostly semi-diurnal at ~15 cm/s).

The map shows bin-2 (at ~32-m depth) over topography, bn2 shows a time series of 5-min averages with my "data quality" indicators after some light screening, H-dev and V-dev are standard deviations of ship's heading (Ashtech) and speed (P-code GPS) witin each 5-min ensemble, and the solif line in both w(t) and v(t) is the ship speed in m/s second for reference. The final station-underway comparison are in stn-udw.ps and stn-udw.ps

Any comments are most welcome.

andreas

P.S.: I ran 8-m narrowband pulses then (much shallow water), however, over the Beaufort slope I am running 15-m narrowband pulses. I am indeed using Ashtech headings only right now but can change that by un-commenting a single line in my code. Perhaps I am lucky :) The .LOG files contain hardly any messages after the cs command. This is very different from when I got onto the ship back in July. I even had one of the 50,000 files/day events that Jules is struggling with. Yikes. I think its a Windows thing. Yikes, again. I miss my DOS and DAS :(

8.3 On calibration

From: Andreas Muenchow <amuenchow@bkr2.rdc.uscg.gov>

Date: Wed Oct 1, 2003 5:17:12 PM America/Anchorage

To: "Charles N. Flagg" <flagg@bnl.gov>

Cc: rwoodgate@sci.uscoastguard.net

Subject: Re: Healy ADCP update

Chas,

The pitch/roll correction is NOT intermittent at all. Just have a look at the vertical bottom-track velocity plotted as a function of ship speed that you may have from last year. It's an almost perfect linear relation for me. More specifically, I get 6 cm/s for 10 kts which translates almost directly into an error in the horizontal velocity. The three rotations I gave are constant offsets that I get from using about 2 weeks days of contineous 5-minute averaged bottom track data. I can do pitch and roll corrections ping-by-ping and/or 5-min by 5-min ensemble, it does not make a difference. It's more like an absolute offset, like a washer or two that set the transducer plate at a crooked angle from the horizontal. Or the beam's orientation are different from it's nominal 30 degrees. Who knows, but I do know that I absolutely need this constant pitch and roll offset in order to use GPS for vessel speed when I don't have bottom track, actually, right now I have a hard time distinguishing between BT and GPS-derived vessel motions. I must also have some luck with the Ashtech as I am using it exclusively, no interpolation, no gyro, just a 5-minute average that I use to rotate 5-minute averages of beam velocities into an earth-referenced co-ordinate system. Wild ...

Perhaps the statements I just made above are a bit too strong as I looked only at this cruise's data closely and I will repeat the exercise for data from Nares Strait earlier this summer and with data from the end of this cruise. I also have the data from the Healy's transit through the North-West passage and a 10-day NOAA cruise all on my little Mac. I should be able to work through the data while aboard. The moment I get home, all hell break loose with regard to other responsibilities. My long absence has been stressful on my wife and the 2 weeks at home in-between did not help much. I promised Jackie to attend the PI meeting this Dec. when I met her in Barrow.

I am quite happy with this cruise so far, we have encountered very little ice and even then, there are plenty of usable pings to form some averages. We have not seen any of the heavy multi-year ice that you endured last year. The data will make it into several fine publications, however, this will become somewhat of a difficult issue as "service PIs" do not have the same standing as "science PIs." We already had a discussion on this very early on and it did cause some friction as Bob Pickart would be perfectly comfortable to do his own ADCP data collection, processing, and analysis. The same applies to hydrography which he actually does do with little help from SIO. It's not quite clear where that will leave us, though. Here at sea we decided to collect and openly share the best possible data set in real time. I put up the processed and calibrated "very preliminary" (but close to final, I think) data onto the public drive for anyone to use and Bob does the same for CTD data. In a way, we put all SBI politics to the side and decided to enjoy ourselves which we do, however, there is a potential skeleton in the closet. The ill-advised person responsible for this has thankfully retired from government service and a Polar Service medal should be awarded to the University of Arkansas :)

andreas

Andreas Muenchow http://newark.cms.udel.edu/~muenchow

College of Marine Studies tel: 302-831-0742

University of Delaware fax: 302-831-6838

Newark, DE 19716 amuenchow@bkr2.rdc.uscg.gov

muenchow@udel.edu

9. Sample Products

9.1 ASCII data files

407419.4 -158.2641 71.1171 1 1.6 -9.6 30.0 0.6 146. 98 0 33.6 -1.3 3.2 7.4 188.0 2

407422.4 -158.2668 71.1173 2 -7.1 1.9 31.0 0.5 180. 98 0 29.9 0.4 -5.0 9.6 186.3 2

407422.4 -158.2668 71.1173 1 9.9 -9.0 31.0 0.5 146. 98 0 29.9 1.1 -0.8 9.6 186.6 2

407425.4 -158.2682 71.1177 2 2.4 -4.8 32.0 0.3 183. 100 0 25.6 0.6 -4.3 8.3 186.3 2

407425.4 -158.2682 71.1177 1 6.3 -11.5 32.0 0.3 148. 96 0 25.6 -0.1 0.5 8.3 188.6 2

407428.4 -158.2681 71.1179 2 18.5 -20.7 30.0 0.5 181. 100 0 25.6 1.2 -0.2 34.1 186.6 2

407428.4 -158.2681 71.1179 1 10.7 -23.6 30.0 0.5 148. 100 0 25.6 1.1 -0.8 34.1 189.4 2

9.2 Readme files:

readme

andreas muenchow, Oct.-17, 2003

University of Delaware

muenchow@udel.edu

The files in this directory are derived from single-ping 75 kHz

Ocean Surveyor ADCP data (the .ENS) files. The following processing

steps have been performed on a Mac Powerbook-G4:

1. extraction of certain data fields from the binary .ENS using

os3adcp.csh, prep-code.csh, and bin3.f

to store single-ping ASCII files

2. conversion from beam to earth co-ordinates;

filtering navigation and attitude data (Lanczos raised cosine)

data screening prior to 3-min. averaging;

screening after averaging;

application of some, perhaps inappropriate calibration coefficienta

using

osadcp.f and adcp_pro.f

The OS-75 allows to send two separate pings and I here experimented with

that capability for the first time. The files named "trans.b##" are from

a BroadBand pulse (5-m bin size, 10-m blanking) while the files named

"trans.n##" are from a NarrowBand pulse (8-m bin size, 10-m blanking). Both

pulses use the same bottom-tracking ping (which may not be quite kosher).

The file format is as follows:

#1: time in minutes after some arbitrary reference (minutes after Jan.-1 00:01)

#2: longitude

#3: latitude

#4: bin number

#5: velocity east (cm/s)

#6: velocity north (cm/s)

#7: bottom depth either from bottom- or water-track (under development)

#8: ship's speed (m/s)

#9: echo intensity (backscatter)

#10: percent good pings (passing screening) water tracking ping

#11: percent good pings (passing screening) bottom tracking pings

#12: standard deviation heading during averaging interval

#13: vertical velocity (cm/s) for quality control

#14: error velocity (cm/s) for quality control

#15: standard deviation of ship speed during averaging interval

#16: signal-to-noise ratio (narrowband) or correlation (broadband)

#17: flag to identify BT (1) or GPS (2) for removal of ship's velocity

The data should be considered very pre-liminary and should not be used or

quoted in any public setting including the SBI community.

andreas muenchow

muenchow@udel.edu

readme.2:

OS-75 kHz ADCP aboard USCGS Healy, SBI-2003 processed data files

(andreas muenchow, University of Delaware, Oct. 17, 2003)

The files in this directory have the following characteristics

dz-1 depth bin of ping-1

blk-1 blanking of ping-1

z0-1 distance to center of the first bin of ping-1

dz-2 depth bin of ping-2

blk-2 blanking of ping-2

z0-2 distance to center of the first bin of ping-2

nbin-2 the number of bin for ping-2

the symbol "#" is either "n" (for NarrowBand) or "b" for (BroadBand)

and ping-1 always refers to the NarrowBand ping while, if indicated,

ping-2 always refers to the BroadBand ping. The same bottom tracking

ping is used to remove the ship's velocity vector for both Narrow-

and BroadBand pings. Hence to calculate the center of the i-th bin

use z=z0+(i-1)*dz to give the vertical distance in meters below the

seasurface, the ~8-m distance of the transducer face is already

included in z0.

file-name dz-1 blk-1 z0-1 nbin || dz2 blk2 z0-2 nbin-2

trans.#02 8-m 10-m 26.0-m 10 04-m 10-m 22.5-m 20

trans.#03 8-m 10-m 26.0-m 25 04-m 10-m 22.5-m 50

trans.#04 8-m 10-m 26.0-m 10 04-m 10-m 22.5-m 20

trans.#05 8-m 10-m 26.0-m 25 05-m 10-m 24.0-m 40

trans.#06 8-m 10-m 26.0-m 25 05-m 10-m 24.0-m 40

trans.#07 8-m 10-m 26.0-m 25 05-m 10-m 24.0-m 40

trans.#12 8-m 10-m 26.0-m 15 05-m 10-m 24.0-m 40

trans.#13 8-m 10-m 26.0-m 15 05-m 10-m 24.0-m 25

trans.#15 8-m 10-m 26.0-m 20 05-m 10-m 24.0-m 25

trans.#16 8-m 10-m 26.0-m 30

trans.#17 8-m 10-m 26.0-m 30

trans.#19 8-m 10-m 26.0-m 30

trans.#20 8-m 10-m 26.0-m 25

trans.#21 8-m 10-m 26.0-m 30

trans.#22 15-m 10-m 33.0-m 40

trans.#23 8-m 10-m 26.0-m 35

trans.#24 8-m 10-m 26.0-m 5 05-m 10-m 24.0-m 10

trans.#25 8-m 10-m 26.0-m 5 05-m 10-m 24.0-m 10

trans.#26 8-m 10-m 26.0-m 5 05-m 10-m 24.0-m 10

trans.#27 8-m 10-m 26.0-m 35

trans.#28 15-m 10-m 33.0-m 40

trans.#29 15-m 10-m 33.0-m 40

trans.#30 15-m 10-m 33.0-m 40

trans.#31 15-m 10-m 33.0-m 40

trans.#32 15-m 10-m 33.0-m 40

trans.#33 15-m 10-m 33.0-m 30

trans.#34 15-m 10-m 33.0-m 20

trans.#35 15-m 10-m 33.0-m 30

trans.#36 8-m 10-m 26.0-m 35

trans.#37 15-m 10-m 33.0-m 30

trans.#38 15-m 10-m 33.0-m 30

trans.#39 8-m 10-m 26.0-m 40

trans.#40 8-m 10-m 26.0-m 40

trans.#41 15-m 10-m 33.0-m 30

trans.#42 15-m 10-m 33.0-m 30

trans.#43 8-m 10-m 26.0-m 10

trans.#44 15-m 10-m 33.0-m 30

trans.#45 15-m 10-m 33.0-m 30

trans.#46 8-m 10-m 26.0-m 10

trans.#47 8-m 10-m 26.0-m 40

trans.#48 8-m 10-m 26.0-m 40

trans.#49 15-m 10-m 33.0-m 30

trans.#50 8-m 10-m 26.0-m 10

trans.#51 8-m 10-m 26.0-m 30

trans.#52 8-m 10-m 26.0-m 15 4-m 10-m 23-m 30

trans.#53 15-m 10-m 33.0-m 30

trans.#54 15-m 10-m 33.0-m 30

trans.#55 15-m 10-m 33.0-m 30

trans.#56 15-m 10-m 33.0-m 40

trans.#57 8-m 10-m 26.0-m 15 4-m 10-m 23-m 30

readme.3:

OS-75 kHz ADCP calibrations for 2003 SBI aboard USCGS Healy

(andreas muenchow, University of Delaware, Sept. 24, 2003)

The following calibrations have been applied to all processed

ADCP data in this directory following routines first suggested

by Joyce (1989):

alpha-1: -44.1 (degrees)

beta-1: 1.00316 (-)

alpha-2: 0.94 (degrees)

alpha-3: -0.90 (degrees)

where

alpha-1 is the misaligment angle in the horizontal (heading) plane,

alpha-2 is the misalignment in the vertical (roll) plane, and

alpha-3 is the misalignment in the vertical (pitch) plane.

beta-1 is the scaling coefficient n the horizontal plane.

Alpha-1 and beta-1 are found from correlating the ihorizontal vessel i

motions derived from the aft-P-code GPS system with those derived

from the horizontal components of bottom tracking.

Alpha-2 is derived from the aft-P-code GPS velocity component in the

beam 3-4 direction that is correlated with the beam 3-4 horizontal

component and the vertical beam 3-4 velcoty component of bottom track, I

here prescribe a zero vertical velocity component for the GPS-derived

vertical velocity of the ship.

Alpha-3 is the same as alpha-2, except it is for the beam 1-2 component.

Only valid Ashtec heading information is used for all calibrations. Ashtec

pitch and roll information is too noisy for ping-to-ping and for 5-minute

averaging. Hence the vertical plane misalignment correction may be

interpreted as a correction for

(a) a mean pitch and roll (ship's list)

(b) a symetric deviation from the nominal 30 degree beam angles, and

9.3 Plots

Fig. 1: Oct. 5, 2003 section of across-shore (top panel) and along-shore (bottom panel velocity component across the Beaufort slope; inverted triangle indicate mooring location. More than 18 of such sections have been assembles with and without accompanying hydrography.

Fig.2: As Fig. 1, but for Oct. 4, 2003.

Fig. 3: The 12-hour segment of the comparison of station and underway ADCP data (Figs 4 and 5). Data are not synoptic as they contain a tidal bias.

Fig.4: Comparison of on-station (line) and underway (symbol) data after calibration as a 12-hour average for east (left panel) and north (right panel) velocity components.

Fig. 5: As Fig. 3, but for the vertical (left panel) and error (right panel) velcoity that is the difference of the vertical velocity from beams 1 and 2 and from beams 3 and 4.

Fig. 6: Map of current vectors at ~100-m depth over the Chukchi continental slope Oct. 15/16, 2003. Note that the flows depicted are NOT synoptic.