Acoustic Doppler Current Profiling
during the Sea of Japan/East Sea SeaSoar Cruise JES2,
May, June 1999
Frank Bahr,
Woods Hole Oceanographic Institution
Woods Hole, MA 02543
fbahr@whoi.edu
http://matisse.whoi.edu
June 29, 1999
Abstract
This report describes the processing of data from the
shipboard Acoustic Doppler Current Profiler (ADCP) that were collected
during the JES2 SeaSoar cruise, a component of the ONR Sea of Japan/East
Sea experiment. The chief scientist was Dr. Craig Lee from the University
of Washington, Applied Physics Laboratory.
Abstract
Table of Contents
2 The ADCP System
2.1 ADCP hardware and transducer installation
2.2 Navigation
2.3 The Data Acquisition System
2.4 The Data Processing Software (CODAS)
3 Cruise Narrative
3.1 Highlights
3.2 General Cruise Log
3.3 ADCP Data Collection
4 Data Processing
4.1 Scan and Load
4.2 Editing
4.3 Temperature and
Salinity Correction
4.4 Ashtech Heading Correction
4.4.1 Background
4.4.2 Processing
4.5 Calibration
4.5.1 Bottom Tracking
4.5.2 Water Tracking
4.5.3 Final Calibration and Rotation
4.6 Navigation
4.6.1 Background
4.6.2 JES2 Navigation
4.7 Profile Quality
4.7.1 Vertical Shear of u, v
4.7.2 Vertical and Error Velocity
4.7.3 Amplitude (AGC) and Spectral Width
4.7.4 Percent Good, and 3-Beam Solution
4.7.5 Summary
8. References
Appendix A: ADCP Configuration files
Appendix B: The UH ADCP data processing
system
B.1 Hardware
B.2 User interface
B.3 Database
B.4 Editing
B.5 Calibration
B.6 Navigation
B.7 Gridding and plotting
The JES2 cruise was part of the Office of Naval Research's Sea of Japan / East Sea experiment. The sensor suite included the WHOI SeaSoar, outfitted with the standard SeaBird hydrographic sensors, a fast oxygen sensor built by Dr. Chris Langdon, a fluorometer and transmissometer, a PAR sensor, as well as the new optical sensors AC100 and Hydroscat 6. In addition, stations were occupied for standard hydrographic and optical measurements. Weather balloons were launched roughly daily, while shipboard meteorological data were collected by the onboard IMET system. The shipboard ADCP was run throughout the cruise.
The purpose of this report is to describe the processing of the shipboard ADCP data. In the following, the instrument system and the data processing software are introduced in chapter 2. Chapter 3 provides a brief cruise log. Specifics on data processing issues such as calibration etc. are given in chapter 4. Some initial figures from the SeaSoar radiators are shown in chapter 5, though scientific description of the measurements will be reserved for other publications.
return to the table
of contents
The ADCP system on the R/V Roger Revelle, operated by
the Scripps Institution of Oceanography in San Diego, can be divided into
several components: the ADCP transducer and its installation, the data
acquisition system computers and software, and the navigation instruments.
2.1 ADCP hardware and transducer installation
The ADCP transducer is a standard (narrow band) 150 kHz
vessel-mounted transducer from RD Instruments. It is located behind an
acoustic window, and is immersed in fresh water (Teri Chereskin, pers.
comm.). The transducer is not rotated by 45 degrees, so that only
beam 3 and 4 "see" the ship's speed.
2.2 Navigation
Several instruments provide additional data to the ADCP that are incorporated either in real-time or during post-processing. These are:
2.3 The Data Acquisition
System
The primary data acquisition is performed by a PC running RDI's Data Acquisition Software (DAS) version 2.48. This software produces the familiar pingdata files ("pingdata.###"), usually one file per day, which were recorded on hard disk. The PC disk was cross-mounted as a unix disk, and the data were available in real-time via the ship's network.
For this cruise, DAS configuration parameters included 4m blanking, 8m vertical bins and a 8m pulse. Profiles were usually collected at a rate of about once per second and vector- averaged in 3-minute ensembles. To reduce spurious shear from simultaneous variations in depth range and ship's speed during an ensemble, the vector-averaging was done in the usual way as follows (using an option in the DAS). For each velocity profile, the mean over a reference layer (here: bins 4 through 12) was calculated and subtracted from the profile. The reference layer and the reduced profile were then averaged separately over the ensemble, and recombined at the end of the ensemble. The DAS option for screening based on error velocity was used with a threshold of 250cm/s. Routine data collection included horizontal and vertical velocity components, backscatter amplitude (as measured by the automatic gain control -AGC- level), percent good pings (at each depth bin, the percentage of pings within an ensemble for which data form all four beams were judged acceptable), error velocity, spectral width, and percent 3-beam solution (at each depth, the percentage of acceptable pings that were calculated from three instead of four sound beams).
The following direct commands were set:
With the present RDI DAS, integrating navigation into
the ADCP system requires a "user exit" program that effectively becomes
part of the DAS. The Revelle used Eric Firing's program, version "ue4.exe".
Its main functions were (Firing, 1998):
Once per second, the Ashtech GPS heading unit sends
out an ATT message, which contains heading, pitch, roll, and quality parameters
mrms and brms. The mrms "is defined as the average double differenced carrier
phase residual" (Ashtech manual). This value is zero if less than 5 satellites
are used in the attitude computation. Typical values are around 2-3mm.
The brms error is defined as "the rms error between the baseline magnitudes
determined in the initial survey (i.e., the body reference frame vectors
between antennas 1-2, 1-3, and 1-4) and the computed baseline magnitude
obtained at the current time. Typical values are 1-3 cm for PDOP<4."
The NMEA GGA sentence includes time (no date), longitude, latitude, HDOP,
number of satellites, and antenna height in meters.
Just prior to our cruise, the ship's computer technician
had installed Dr. Charles Flagg's AUTOADCP software. It is my understanding
that the software was originally developed for autonomous ADCP data collection
on ship's of opportunity, e.g., on the merchant vessel Oleander. It consists
of two parts: a watchdog timer, and a configuration update based on the
ship's geographic position. The task of the watchdog timer is to reboot
the PC in the event that it gets hung up. The configuration update routines
compare the ship's position relative to geographic areas defined as polygons
in the ASCII file POSITIONS.DAT. Each polygon is associated with one ADCP
configuration file. If the ship enters into a new polygon, the respective
configuration file is copied over the DAS file START.CNF, and the ADCP
acquisition PC is rebooted. This feature has been used to allow, for example,
for different deep and shallow water values for configuration parameters
such as bin and pulse length or to toggle bottom tracking on and off. Since
we used one configuration throughout the cruise (and were able to toggle
bottom tracking manually), I disabled the configuration update by substituting
a new POSITION.DAT file with just one large polygon that encompassed the
whole cruise. Rather than modifying Charlie's setup, I implemented this
change by creating a new directory as a complete copy of the original one,
changed the POSITION.DAT in that new directory, and modified the AUTOEXEC.BAT
file to cd to the new directory on startup instead of to the original one.
2.4 The Data Processing Software (CODAS)
The ADCP processing software used here was developed by a group from the University of Hawaii led by Eric Firing. CODAS (short for Common Oceanographic Data Access System) consists of a database system for ADCP and other oceanographic data, and a set of programs for ADCP data processing. The programs are written in C and matlab. To obtain the source code and executables for several platforms including PC's, SUN and SGI work stations, contact efiring@soest.hawaii.edu.
The software package is outlined in below, following closely
chapter 8.1 of Firing, 1991. A more detailed description of the software
is given in Appendix B of that document, included
here as an appendix as well. The complete document is available as postscript
file via anonymous ftp (ftp://noio.soest.hawaii.edu/pub/codas3/opmeth.ps).
An extensive 200-page manual is available as postscript file from the same
account (ftp://noio.soest.hawaii.edu/pub/codas3/manual.ps). The software
package includes a demo database and example parameter files that were
used for the various processing steps; a corresponding step by step process
log is found in the ascii file codas3/adcp/demo/process.doc. In addition,
the following text files were included in my April 1998 copy of CODAS:
codas3/notes.doc
codas3/vecplot/vector.doc
codas3/adcp/demo/ADCPdemo.doc
codas3/adcp/adcpsect/note.doc
codas3/adcp/edit/adcpedit.doc
codas3/adcp/cal/adcp_cal.doc
codas3/adcp/scanload/scanload.doc
codas3/adcp/nav/adcp_nav.doc
codas3/adcp/doc/dpmask.doc
codas3/doc/codas3.doc
codas3/doc/update.doc
codas3/ctd/demo/ctd_demo.doc
codas3/note_sun.doc
The specific processing steps for the JES2 data set are described in chapter 4.
The basic data processing steps consist of:
3.1 Highlights
Chief Scientist: Craig Lee
Phone: 508-289-2599
e-mail: craig@sahale.apl.washington.edu
Ship: R/V Roger Revelle
Ports of Call: Pusan, South Korea to Pusan, South Korea
Dates: May 19 to June 2, 1999
3.2 General Cruise Log
A detailed cruise log is currently being prepared by Dr.
Lee.
3.3 ADCP Data Collection
The general ADCP data collection worked without major problems.
Early into the cruise, captain Desjardin made us aware of some lingering concerns by Scripps people regarding possible interference of the ship's 10cm radar with the Ashtech GPS heading data collection. The Ashtech array is located close to the 10cm radar antenna. Although no such interference was obvious from a few checks of the ADCP screen where the userexit program lists the number of good GPS headings accepted during the last ensemble, we encouraged the bridge to use the 3cm radar whenever possible. A closer inspection of the GPS record fell victim to the busy early stages of the cruise. As the cruise progressed we were made aware that the bridge relied more and more on the 10cm radar, which is typically only used in heavy traffic, because of some problems with the 3cm instrument. About six days into the cruise we obtained a log from the bridge that listed the usage times of the two respective radars. We then compared the complete ue4-collected Ashtech record up to that time for any signs of interference. Neither the number of good Ashtech headings per ADCP ensemble, nor the heading standard deviation within an ADCP ensemble showed a dependence upon radar usage.
return to the table
of contents
In this chapter, the processing steps for this dataset
as well as cruise-specific issues and problems are described. Although
the underlying concepts are briefly described and the relevant CODAS program
names are listed, a reader looking for a guide to CODAS ADCP processing
would be better served with the documents referred to under chapter
2.4.
As the first step, the raw data files were scanned for readability, gaps, and clock drift (program scanping). There were 29 pingdata files, pingdata.000 through pingdata.028.
Typical values for beam statistics, which are compiled by scanping for each pingdata file, were as follows:
Statistics for Beam Statistics (scaled by 1.000000)
beam
N MEAN STD DEV
SEM minimum maximum
1
250 94.388 6.405
0.405 72.000 99.000
2
250 92.088 5.971
0.378 72.000 99.000
3
250 90.964 6.398
0.405 71.000 99.000
4
250 89.860 5.802
0.367 71.000 97.000
END OF FILE: ../ping/pingdata.022
During the preliminary processing onboard the ship, an ADCP gap was noticed at the start of the cruise (decimal day 138.3044907, 1999/05/19 07:18:27.99 to decimal day 138.4349421, 1999/05/19 10:26:18.99). This was idenfied in post-processing as a gap in GPS coverage, not in the ADCP data collection. This gap started with the second ADCP ensemble of pingdata.000. It coincides exactly with a gap in Ashtech heading data, which comes from a different GPS system and via a different serial port. It is unclear what caused the gap.
A short gap in the ADCP data of 17 minutes occured on 99/05/29 03:17:05, decimal day 148.136863 (ending time). Again, it is unclear what caused this gap.
The PC clock is used for time-stamping the ADCP profiles. It can be checked by comparing profile times with GPS fix times, which is routinely done as part of the scanning. The userexit program ue4 can be instructed to reset the PC clock during data collection if the difference between PC and GPS time becomes larger than a value set in ue4.cnf. As a sefeguard against bad GPS times, a second value is set in ue4.cnf as an upper limit for the change of PC-GPS times over the course of an ensemble. The routine values of 2 seconds for these two parameters were used during this cruise, and the scanping output confirmed that the PC clock was within 2 seconds of GPS time.
The data were then loaded into the newly created jes2 database without time correction (program loadping). After loading, the CODAS data processing mask looked as follows:
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0000 0000
0000 0000 0000 0000
The general concepts behind the profile editing steps are described in Appendix B, chapter 4 (Firing, 1991). In summary, there are three steps. First, threshold values for a set of database variables are calculated from general statistics (program profstat). Next, the complete database is examined in matlab using stagger plots of a suite of variables that may include the three velocity components, amplitude (AGC), percent good, error velocity, and position. (I found a simple plot of ship's speed through the water, given roughly by the reference layer velocity stored in the variables U_MEAN and V_MEAN, helpful to identify station times, SeaSoar deployment and recoveries etc.) The profiles or bins that exceeded the specified thresholds are automatically marked, with differently colored symbols indicating which criterion was exceeded. Based on these plots, the decision is made of what to edit. Possibilities include specifying the first or last bin for which the velocity data are considered valid (e.g., in cases of inadequate surface blanking or bottom interference, respectively), marking individual vertical bins as "bad" by setting the corresponding bits in a quality array (e.g., when a few bins show glitches due to CTD wire interference), or in extreme cases marking a complete profile as "bad" (e.g., for very shallow bottoms in port). The final product of the matlab examination are two ascii lists that identify the "bad" profiles or bin ranges, respectively. They are used as input to a set of programs that actually implement the editing changes in the database.
Around 1994 some technical changes were made to the editing
programs, modifying the steps described in some of the older example databases.
I often refer to an email from Eric Firing
that describe the modifications.
4.2.1 Thresholds
The specific threshold variables and their values used for this dataset are listed in table 1. Standard values were used for the first two variables. Estimates for the others were calculated as follows (using CODAS routine threshold.m):
| Criterion | Threshold calculated | Threshold used |
| Amplitude (AGC) | N/A | 10 counts |
| error velocity | N/A | 100 mm/s |
| 2. difference of u,v | 116 | same |
| 2. difference of w | 61 | 100 |
| w variance | 2190 mm^2/s^2 | same |
Table 1: Editing criteria. The central column shows the calculated thresholds, the right column shows the thresholds that were eventually used.
4.2.2 Specific Editing Issues
In general, the velocity profiles were very clean.
The most distinct editing feature was the high number of scattering layers found. These are layers that generate a subsurface maximum in backscatter amplitude, and thus have a signature similar to that of the bottom. Those that are caused by passive particles or at least slow swimmers such as plancton do not contaminate the horizontal current measurements. The decision of that is a harmless scattering layer and what is the bottom needs to be made by the data processor. A frequent clue is that a true bottom signal should get stronger as the bottom rises, whereas biological scattering layers frequently just fade away. Furthermore, fake velocities from depth bins below the true ocean depth are usually more random than actual measurements with velocity features that develop over consecutive profiles. For this cruise, the scattering layers persisted over long times, and were comparatively strong. Most of the time there was no obvious correlation between scattering layers and velocity features. At times, however, a particular velocity gradient region coincided with a scattering layer. In contrast to bottom interference, however, these velocity features were consistent over several or many profiles.
Identification of the relatively few occasions of a real bottom were on several occasions made more difficult by the partial (but not complete!) elimination the bottom interference by the percent good criterion. The picture was then further complicated by a scattering layer above the real bottom. In those situations it may be easier to temporarily turn off the percent good editing to correctly mark the bottom, as it was done for the example plot of backscatter amplitude (AGC) (set PGOOD_THRESHOLD to 0 and reload profiles with getp). In this plot, the maximum in AGC by which the editing routines identify the bottom is marked with a blue star. The actual bottom is around bin 35, while one or more scattering layers above it are seen above it. [Profiles marked with purple stars were flagged by the w-variance criterion, which flags the complete profile rather than individual bins.]
The only real data quality issue were about five cases of curious sequences of very large error velocity e and vertical velocity w in conjunction with somewhat odd features in zonal (u) and meridional (v) velocity. Typically this pattern is indicative of CTD interference when the profiling CTD package drifts into one of the ADCP beams. In this first example (profile times approx. 5/24 11:00), the ship was initially on station, but w di not increase (and a corresponding signal in u and v developed) not until the ship picked up speed, and thus CTD should have be on deck.
Second, smaller group was found late in the cruise (around 05/31 11:00). In a range of mid-level bins, vertical velocities were of the order of 30 cm/s over a series of profiles. Zonal (u) and error (e) velocity showed less of a corresponding signal, while a small subset of profiles had extrema in meridional velocity (v) in this area. Again, this set occurred close to a ship speed change, although in this case speed increased from four to eight knots after a SeaSoar deployment. The first profiles with large w occured just prior to the speed change.
A third case was flagged on the second-to-last Seasoar recovery (6/1, 16:00) and its associated speed changes. Large w values (order 30 cm/s) occured during a stepwise reduction in speed to below four knots, and continued just beyond the following speed increase to 12 knots. Corresponding error velocity profiles showed some corresponding signal (which triggered the automatic editing of large e, indicated by the yellow circles), while both horizontal velocity components appear little effected [Note: these profiles are shown in their unedited form; the deep velocity maximum is caused by bottom interference and was subsequently taken out].
One or two (depending on the counting) much smaller, less distinct cases were found in the remainder of the cruise.
I exchanged several emails including figures with Teri Chereskin from Scripps on the subject. She had previously noted a problem with transducer ringing. According to her, steps had been taken to correct the problem, but she was concerned that some effect remained. She wrote:
We used the Revelle narrowband in January, and it had an acoustic ringing problem. Adjustments were made during the February shipyard period to try to eliminate the ringing.
Acoustic ringing is most apparent during ship accelerations, such as when you leave station - on a CTD cruise I'd expect to see it as you got underway from every station. It might be much more subtle in a SeaSoar cruise. When ringing is really bad, you see it in all the data, and it gets worse as you increase the speed, at full steam you might even lose profiling. The anomalous horizontal current is in the same direction as the ship speed. Percent good is low in the surface layer where it's usually high.
The apparent shear arises because the beams that measure the ship speed aren't tracking; they're staying locked onto the zero Doppler shift of the ringing. The ringing is the stronger signal but attenuates faster, so often the far range bins do pick up the water echo signal. Subtracting the ship speed out from the mix of biased and unbiased bins gives you the shear. W is the average from beam pairs 1-2 and 3-4. Error is the sum of the 4 beams. If the errors in beams 3 and 4 don't cancel, then you could get a signal in w or error velocity.
Revelle was not that bad, and I'd mainly look for it during accelerations.
I followed Teri's suggestion and looked at other ship accelerations. The following example from a CTD station departure contains some of the highest accelerations of the dataset. The meridional velocity (v) showed somewhat higher near-surface shear during high ship speed. However, the sign of shear at the shallowest bin is "wrong" since the ship headed southward (positive meridional reference layer velocity).
In another example, near surface shear changed gradually over a long series of profiles, and did not follow the very ubrupt drop in ship speed.
On the other hand, surface velocities displayed curious "hooks" at times. In this example, zonal velocity shear increased with a course change. Again, bin 1 velocities were increased relative to the vertical mean, rather than decreased for ringing. Is it possible that the effect would not arise until bin 2?
Percent good will probably look ok. Spectral width might be abnormal. Instead of going from low to high with range, indicative of good SNR and a good peak corresponding to the Doppler shift measured in the low-pass tracking filter, it will be large in the upper bins, since the ringing is a strong signal but relatively white.
Beams 3 and 4 see the ship speed on Revelle, and so I'd expect high spectral width on those beams, if you recorded beam spectral width. Spectral width and last raw Dopplers are useful for this diagnosis.
I am not familiar with separate spectral width data for each beam, nor is it quite clear to me what setting in the start.cnf file would allow it to be collected or where it would be stored in a CODAS database. We did collected average spectral width for each bin. Looking again at the case from 5/24, 11:00, properties of on-station profiles (Blk 10, Prf 200:220) was compared with those of underay profiles (Blk 10, PRf 230:237). Underway meridional (v) velocity following the speed change included large shear in the bin range 4:7, centered on 42 to 66 meters. Spectral width from underway data was somewhat enlarged between bins 2 and 10. It is highest, however, for bin 1 on station. On station amplitude showed a similar maximum for bin 1. For completeness, vertical (w) velocity and error (e) velocity for the same time ranges are included here, with mean w and e profiles displaying a peak in the area of anomalous v shear. Percent-good and pecent-3-beam solution showed standard profiles, except - again - for a drop in underway mean for bin 1.
Ringing is certainly a possible explanation for what you see in example 4 [referring to the plots from 5/24 11:00, fb], but I would expect you to see it on ALL similar speed changes. Did it appear only at the end of the cruise? [using the same editing thresholds for the whole cruise, w variance only flagged cases following 5/24, and not all instances of speed changes then either; fb]
On the January CalCOFI, we saw strong (erroneos) shear in the depth range 30-50 m, using a 12 m blank. The hope was to eliminate this problem, or at least improve it.
Based on all the cases I have looked at, I do not think that this dataset has a significant ringing problem. Bin 1 and/or bin 2 show some questionable shear at times, but it does not seem to coincide with the conditions that go with ringing (i.e., dependence on ship speed). Also, I do not think that the instances of suspicious features within the upper 10 bins described above are caused by ringing. For once, ringing should have effected profiles from similar conditions throughout the cruise, whereas many examples of ship velocity changes showed clean profiles.
There was some question as to what to do about these cases. Horizontal velocity profiles often showed little or no adverse effect, although such interference was difficult to rule out in cases of quickly changing velocity features. While error velocity was large in the first case, indicating a change in the velocity field between the ADCP beams, it was typically only w that showed large values. Particularly for the third case, the w signal started very ubruptly, between the 5th and 6th profile of the group shown here, while it disappeared in a more gradual fashion. What could have happened at the time of the speed reduction? It is highly unlikely that any gear was lowered over the side without the ship being stopped. Perhaps these features could be somehow connected to the bow thruster, which might have been used to help maneuver the ship at times of instrument recovery / deployments. Why did these cases show up only in the later part of the cruise? They were very obviously flagged by the w-variance criterion. Did the bridge change its pattern of ship handling? In the end, I decided it was more cautions to edit out the affected bins (as defined by large w) because a vertical velocty of 30 cm/s, associated with a pattern of ship speed, suggested that something artificial was introducing these measured water velocities.
Once the matlab routines finished listing all the profile glitches, bottom interference etc. in the ascii files badbin.asc, badprf.asc, and bottom.asc, a series of CODAS routines was run to implement the edits in the database:
badbin ../adcpdb/jes2 badbin.asc
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0000 0000
0000 0000 0100 0000
dbupdate ../adcpdb/jes2 badprf.asc
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0000 0000
0000 0000 0100 0000
dbupdate ../adcpdb/jes2 bottom.asc
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0000 0000
0000 0001 0100 0000
set_lgb ../adcpdb/jes2
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0000 0000
0000 0011 0100 0000
setflags setflags.cnt
with setflags.cnt:
dbname: ../adcpdb/jes2
pg_min: 30
set_range_bit
time_ranges:
all
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0000 0000
0000 0011 0100 0000
return to the table
of contents
4.3 Temperature and Salinity Correction
"For non-obvious reasons, the constant of proportionality between Doppler shift and water speed involves the speed of sound at the transducer only." (Firing 1991, page 7, paragraph "Sound speed") It is calculated by the DAS based on the temperature measured by a thermistor embedded in the transducer head, and based on the constant salinity specified in the DAS configuration file (start.cnf). Sound speed depends most strongly on temperature, changing by 0.3% per degree C at 0 degree C, and 0.13% per degree C at 30 degree C; its salinity dependence is about 0.1% change per psu (E. Firing, 1991).
To check the ADCP transducer thermistor, the sea surface temperature records of the Revelle's underway system was extracted from the CD we had received from the computer technician Mark Silver at the end of the cruise. Its subdirectory "met" contained files with names like "990519.dat.Z", which were uncompressed on the SUN into daily ascii files. Following the comment header, the various underway data in each text line were identified by a leading 6-character string. I selected the "INSSSV" message, which, according to the comment section, contains "Surface sound velocity, salinity, corrected temp and conductivity". The nature of the correction was not given. As a check, I compared this temperature record against all available SeaSoar temperatures from depths within 1 to 6 meters, and found good agreement.
The ship's underway temperature and the ADCP temperature were not identical. However, the differences were not of a nature that I had seen before in other ADCP datasets. Typically, one might find a constant offset, a drift of the ADCP thermistor, or even a failure indicated by a constant 40 degrees C. In this case, the general shape was similar, but ADCP record showed an overall smoother shape, minimum values were not as low, and there was some indication of a time delay. These features seemed consistant with some thermal shielding of the transducer by the acoustic window and the freshwater bath, and no transducer correction was applied.
During the cruise, the ADCP salinity had been set incorrectly to 36 psu. This was a setting we "inherited" and seemed quite reasonable at the time, since we did not yet know about the acoustic window. Since the difference to the real salinity at the transducer heads, presumably 0 psu, was constant, the resulting error should be a constant factor as well. Thus it will be corrected by the amplitude calibration lateron, and no salinity correction was applied at this point.
return to the table
of contents
4.4 Ashtech Heading Correction
4.4.1 Background
Gyro compasses on ships are known to have errors that
can reach two to three degrees or more (Bowditch 1977).
One portion of the errors can be described as
Delta= 0.0635 S cos(theta) sec(L)
with ship speed S in knots, and heading theta and latitude
L in degrees (Griffith 1994, Bowditch 1977). The gyro
compass has dials with which speed and latitude can be adjusted by the
ship's crew to reduce such errors. However, even correct
adjustments do not eliminate all errors (e.g., errors in the gyro compass
mode). In recent years, heading devices based on GPS
differential phase measurements between a reference antenna and threeother
antennas have become available (King and Cooper, 1993). The R/V Roger Revelle
has been outfitted with a system made by the company Ashtech.
In summary, the Ashtech heading correction is applied
as follows. Firstly, it should be recalled that each ADCP ping is rotated
into ship's coordinates using gyro heading before the ensemble average
is calculated. Only the ensemble average, not the raw pings, are recorded
in the pingdata files (a feature of RDI's DAS). The Ashtech heading is
not substituted for gyro heading at the raw data stage because it is considered
not reliable enough. Throughout the ADCP ensemble, the userexit program
ue4.exe collects Ashtech heading, edits it based on GPS quality parameters,
and compares it to the ship's gyro heading. Statistics of the heading difference
(mean, std, etc.) are recorded in the user buffer of each ensemble. In
post-processing, the time series of heading difference is further screened
and edited in matlab. At this stage, small gaps may be filled by interpolation
("small" is defined below). The final heading difference time series is
then used as input to a database rotation, which transfers the heading
reference from gyro to Ashtech. A possible constant Ashtech heading offset
(due to a misalignment of the Astech antenna array relative to the ship's
axis) will be corrected, together with a possible ADCP transducer misalignment,
in the subsequent ADCP calibration.
4.4.2 Processing
During data collection, ue4 screens the incoming Ashtech heading data (ATT message) and rejects them if
In post-processing, the program ubprint extracts the heading difference (dh) time series from the database and (for the ubprint.cnt settings used here) deposits it into an ascii and a matlab output file. The m-files ashrot.m, located in the subdirectory cal/rotate, loads the matlab file and further screens the time series based on
Time series of Ashtech minus gyro heading (dh) typically show a combination of long-term gyro heading changes, sometimes correlated with ship's heading, and shorter-term so-called Schuler oscillations of the order of one to two hours triggered by an acceleration (turn) of the ship (e.g., Bahr and Joyce, 1997). The dependence on ship's heading has been used to generate a model to fill larger (longer than one hour) data gaps (Bahr and Joyce, 1997). However, the heading dependence of dh is not always clearly established; furthermore, such a model cannot reproduce the short-term dh oscillations. Fortunately, the only longer gap that required filling occured during relatively constant ship's speed and heading, so that simple linear interpolation was the best choice. It is used routinely to fill shorter gaps. A subjective visual inspection of the final Ashtech minus gyro heading time series (continued: page 2, page 3) provided the last check.
Finally, ashrot.m wrote an ascii output file that spercified a rotation angle for each profile. This rotation was then applied to the database (program rotate), changing the heading source from the gyro compass to the Ashtech GPS array.
return to the table
of contents
Basic methods for ADCP calibrations are explained in Joyce (1989) and Pollard and Read (1989). For the JES2 dataset, we have used two approaches: bottom tracking, and water tracking. These two methods should give identical results for the transducer orientation, but can give scale factor differences of the order of 0.5% (Firing, 1991). Below, the two methods are first discussed individually, followed by a summary of the final calibration.
4.5.1 Bottom Tracking.
In the bottom track method, the ship's displacement over the ground as measured by the ADCP is compared with the ship's displacement measured by navigation fixes. A scale factor A and a phase phi are calculated that, when multiplying the uncorrected bottom track velocity vector Uu = u + iv in the form
Uc = A * exp (i * phi * pi / 180) * Uu ,
minimize the difference between the integrated corrected bottom track velocity Uc and the ship's track as given by the navigation (GPS) fixes. Phi is the counterclockwise angle in degrees between the gyro compass forward axis and the transducer forward axis. Obviously the water depth must be such that the ADCP can reach the bottom. Excluding extremely shallow and deep depths were results might be questionable, the bottom tracking range for a 150 kHz transducer reaches from about 40 to 450 meters. Steeply sloping bottoms such as around mid-oceanic islands can introduce problems. Calibration runs do not have to be straight, though a long horizontal extent is advantageous. Depending on the quality of GPS fixes, bottom tracking as short as one hour may provide good results, with longer runs preferred. The length of a useful segment is given by the time during which bottom tracking was contiguous.
Until recently, the standard CODAS bottom track calibration would calculate one set of amplitude and phase by fitting a contiguous series of ADCP bottom tracking to the corresponding record of GPS fixes. Residuals of the fit, as well as the stability of the calibration values to successive removal of the largest outlier fixes, provide quality parameters. Alternatively, one can calculate a time series of amplitude and phase, one per GPS / ADCP bottom track pair, from the ADCP and GPS time series. While individual amplitude / phase pairs would be too noisy to be meaningful, their mean provide a results similar to that of the previous method. In addition, one gains information about any possible change of calibration over time (e.g., if this operation was done before the Ashtech rotation). Since this approach involves a few programs written by Bahr (fb) that are not described in the CODAS documentation, its steps are listed below.[The core of it, however, goes again back to a program by Eric Firing.]
First, the complete bottom track (BT) record was extracted from the database (program lst_btrk). The resulting output file separated contiguous BT segments with "%" signs. Since one of the subsequent codas routines requires a separate run for each contigous segment, the BT record was broken up into individual, consecutively numbered files containing one segment each (read_bt.plx, perl routine by fb). Very short BT segments, expecially when their bottom depths were very large, were deleted (script rm_it.src). The codas routine refabsbt was then run for all remaining BT segments; as this could require many separate runs of refabsbt, the perl script call_refabs.pl (fb) automatically wrote the required control files and called refabsbt for all BT segments within a specified number range. This range only needed to include the first and last segment number, since missing segments (that were eliminated as too short) only caused an error message without further consequences. The next step in matlab required a time series of heading, since calibration results were also plotted as a function of heading (run lst_hdg). In matlab, the script call_btcaluv.m calculated the time series of amplitude and phase and generated summary plots for each BT segment (edit call_btcaluv.m to specify the segment numbers you wish to process). After pausing, the time series from each was appened to the file btcaluv.dat.
Beyond those general steps, the first, longest BT segment was edited to exclude a period of vey low to zero ship's speed. Although btcaluv automatically edits out data from ship's velocity below a set threshold (here: 2 m/s), which in this case eliminated the worst point with phase <-100 degrees, a few points beyond the automatic editing produced phases of up to one degree above the mean. Suspecting that they were associated with uncorrected compass errors around the abrupt speed change, I inspected the Ashtech record for anomalies or gaps. None were found, but it was confirmed that the Ashtech recorded strong gyro fluctuations at this time. In addition, two clear outliers with amplitudes of less than 0.96 were eliminated from the combined file btcaluv.dat as well. The remaining series consisted of 286 points.
Finally, btcaluv.dat was loaded into matlab to generate plots of amplitude and phase time series, as well as a plot of phase as function of heading. The latter was to serve as a check on the Ashtech heading correction; no remaining dependence of "ADCP alignment" on heading was apparent. For comparison, the corresponding figure without Ashtech correction suggested some heading dependence of bottom track phase, indicative of gyro errors, although the heading range was poorly sampled. Mean and standard deviations for both cases were:
4.5.2 Water Tracking
Amplitude Phase mean 0.9714 -2.2687 std 0.0030 0.2094 mean, no Ashtech 0.9713 0.9088 std, no Ashtech 0.0038 0.3058
In the water track or acceleration method, ship's accelerations
relative to the water measured by the ADCP are compared
to accelerations over the ground measured by GPS. Any substantial
accelerations of the ship during good GPS coverage can
be used. On a normal hydrographic cruise, most calibration points are usually
obtained from station arrival and departure. Sharp turns in the cruise
track provide calibration points as well.
To derive a time series of water track calibrations, first ship's velocities relative to the water were computed from each ADCP ensemble by vertically averaging over a suitable layer. The idea is to choose a layer that shows smooth variations in velocity over time. A standard range is bins 5 to 20. For preliminary results during the cruise, a shallower range of bins 4:12 was used to include more of the shelf waters. Since this range coincided with the problem areas addressed in the editing section, a second, deeper range of bins 11:20 was tried as well. However, these two bin ranges produced only insignificant differences (see table below). Next, the reference layer record was searched for accelerations defined by speed changes of more than 3 m/s, or heading changes for more than 60 degrees while ship's speed was at least 2 m/s (program timslip). For each acceleration, the ship's velocity over the bottom (calculated from the 3-minute GPS fixes) and relative to the reference layer was averaged over a set of profiles. The set configuration can be varied with the aim of reducing the scatter over a group of calibration points. Here, we used the standard option of averaging over three ensembles, each group separated by one ensemble from the velocity jump (timslip options: 9 ensembles, 1:3, 6:8). Finally, a phase phi and a scale factor A were calculated by adjusting thereference layer velocity difference dUref = Uref,after - Uref,before (with U=u+iv as before) to the absolute velocity difference dUGPS = UGPS,after - UGPS,before in the form
dUGPS = A * exp(i * phi * pi/180) * dUref
(Before and after refers to the timing relative to the ship's velocity change). Again, is the counterclockwise angle between the heading forward axis and the transducer forward axis.
In matlab, the initial sets of 83 (78) points were edited
down to 75 (74) by excluding outliers based on thresholds
for amplitude (required to be within 0.04 of the median),
phase (required to be within 3 degrees of the median), variance of the
reference layer velocity within a set (less than 0.05, program adcpcal.m).
Values in brackets indicate those for bin-range 11:20. Additional criteria
based on time shifting of the GPS fixes and on the size of the velocity
jump were disabled by large thresholds. Time series
of the original and edited amplitude and phase showed the usual scatter,
but mean values listed below confirmed the bottom tack values.
Amplitude Phase mean, bin 4-12 0.9737 -2.2971 std, bin 4-12 0.0086 0.3439 mean, bin 11-20 0.9711 -2.2713 std, bin 11-20 0.0072 0.3670
4.5.3 Final Calibration and Rotation
Results from the bottom track and water track methods did not differ significantly. Since the number of water track calibration points was somewhat small - not too surprising given the few CTD stations and long segments of straight cruise track - the bottom track values were taken as the final values. The relatively small amplitude factor reflects the incorrect transducer salinity used during the cruise (T. Chereskin, pers. comm.) The complete database was rotated using the values in the top line of the bottom track table (program rotate).
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0000 0000
0000 0011 0100 0110
return to the table
of contents
In this chapter, the conversion of ADCP velocity profiles
relative to the ship to absolute velocity profiles
is described. It begins with a general discription of the procedure,
followed by cruise-specific issues or problems.
4.6.1 Background (based on Firing 1991, chapter 6)
The approach taken here involves the intermediate calculation of the absolute velocity of a reference layer (e.g., Wilson and Leetmaa, 1988; program adcpsect) rather than calculating the absolute ship's speed directly by differencing GPS fixes. It is based on the assumption that the velocity of an oceanic layer will vary slower in time than the ship's velocity, and therefore short-term velocity fluctuations can be identified as GPS fix errors.
For best results, the reference layer should be chosen such that its velocity varies as smoothly as possible along the cruise track. In general, this would be the thickest layer that contains good data, excluding the first few bins for surface effects. A typical range (and the CODAS default) is bin five through 20.
Secondly, a time series of GPS position fixes is needed. The userexit program used here as part of the ADCP data collectionrecorded two GPS fixes in the user buffer of each profile: the first and last fix available during the ensemble acquisition. Since the acquisition PC needs some time at the end of an ensemble to write the data etc., these two fixes are typically a few seconds apart. Under the option used here, the fix retrieval program (ubprint) averaged these two fixes to calculate a position as close to the end of an ensemble as possible.
For each profile, the absolute velocity of the reference layer was then computed as the difference between the velocity of the ship over ground, determined from the fixes, and the velocity of the ship relative to the reference layer (which is, of course, given by the reference layer velocity multiplied by -1). GPS position errors show up as an anomalous current in one direction, immediately followed by a similarly large anomalous current in the opposite direction. This initial estimate was smoothed by convolution with a Blackman window function w(t) (Blackman and Tuckey, 1958) of width T,
w(t) = 0.42 - 0.5 * cos(2 * pi * t / T) + 0.08 * cos(4 * pi * t / T).
The choice of the filter width depends mostly on the quality of the fixes. See chapter 6 in Appendix B for further thoughts by Eric Firing about the filtering. The estimates of reference layer velocity are plotted for the whole cruise, along with ship's position. These plots are routinely examined for large outlier fixes, which would then be manually excluded from the record. The plots also serve to document other important aspects of the ADCP data set such as the spatial coverage, the general quality of the GPS fixes, and the degree to which particular current features are resolved in the smoothed reference layer velocity.
The smoothed estimate of the absolute reference layer
velocity is added to the velocity of the ship relative
to the reference layer to give the final estimate of the ship's velocity.
The latter is then integrated over each segment of nearly continuous ADCP
data and fit to the ensemble of position fixes within
the segmentl to generate the ship's track. The ship's position and velocity
for each profile is written back into the ADCP database
(program putnav). One could add the ship's velocity
to the velocity profile and then store the resulting absolute profile,
but the CODAS software instead does this calculation
as needed when extracting the data for plotting and analysis (program adcpsect).
4.6.2 JES2 navigation
The standard reference layer bin range 5-20 combined with a short smoothing window (halfwidth 15 minutes) produced worked well for nearly all of the cruise, but produced some suspicious short-term fluctuations in meridional velocity during the departure from the coast on the last day of the cruise. The timing brought to mind the periods of anomalous vertical shear that occured around station departures late in the cruise, and were discussed in the editing chapter. A check with the matlab editing routines, however, showed that they were not present in this particular case. Instead, velocity profiles had been sharply shortened by bottom interference, changing the vertical extent of the reference layer between successive profiles as well as generally restricting it to a shallow, energetic range. In addition, because the bottom interference was complicated by a mix of multiple bottom echoes and false scattering layers, some clearly anomalous velocity spikes had slipped through the editing process. Eliminating these spikes produced only little improvement, however. [ But their presence did trigger a complete re-run of the manual editing to search for other lapses.] A somewhat less dramatic case on June 1st, 16:00, was, however, caused by a reduced bin range due to editing of anomalous shear. Since the editing had eliminated bins down to bin 20 in this case, extending the reference layer down to bin 25 provided a slight improvement, and perhaps even improved the overall record. Finally, a new spike appeared following the edit repeat. When saving real edits, a single scattering layer mark was left uncorrected and was saved as a feature to be edited out. It wiped out most bins of the reference layer. The profile was restored by re-running setflags with the clean_all_bits option.
A test run with bin range 11 through 20, designed to avoid the bins where most of the anomalous shear had been found, showed generally little difference to the 5-20 range, and most importantly did not result in a smoother reference layer velocity. The only significant consequence of this change for the whole cruise record was the replacement of the suspicious segment of the last day with a gap. I
The overal record showed exceptionally clean reference layer velocities, indicative of the high GPS fix quality that could be expected from a P-Code receiver. However, a two to four hour segment around decimal day 143.9 showed significantly elevated noise. It did not change under various reference layer bin ranges. Curiously, the onset of the noise in meridional reference layer speed, which was accompanied by a jump in the mean, coincided with a course change of the ship. However, the return to normal conditions, as well as the noise in zonal speed, were not related to course (or speed) changes.
Based on the overal excellent record, the smoothing filter half width was further reduced to 7.5 minutes. This allowed a better tracking of the shallow reference layer on day 152 without causing spikes in the smoothed record during day 143. The navigation steps were concluded by running the program putnav, changing the data processing masks to:
data_mask ----------> 0000 0000 0000 0000
0000 0011 1000 0001
data_proc_mask -----> 0000 0000 0011 0000
0000 0011 0100 0110
[Note: retaining the short-term reference layer velocity fluctuations that can result from the quickly changing vertical extend of the reference layer, rather than accepting a gap in absolute velocities, is somewhat contrary to the underlying idea of choosing a slowly varying reference layer. The smoothing could then reduce true velocity fluctuations together with GPS errors, and thus cause absolute velocity errors. Weighing the disadvantages of both cases in light of the scientific objectives for this dataset, I decided to keep the shallow data. The high quality of the P-code GPS contributed to this decision, as mentioned above. This may in general not be the best way to proceed.]
return to the table
of contents
ADCP profile quality is routinely checked with several statistics, calculated separately for underway and on station data. A cruise may be broken into several segments and analyzed separately; for the plots shown here, data from the whole cruise were used.
To identify time ranges of underway and on station data, the relative reference layer velocity (ADCP velocity averaged over bins 5 through 20, relative to the ship) were searched for speeds larger or smaller than 2.5 m/s, or about 5 knots. CODAS provides the program arrdep to identify underway and on-station times based on reference layer speed. A run with the default settings from the demo database, however, only produced short time ranges centered on the time of the speed change, rather than the times inbetween the speed change. As I vaguely recall, the time range file used to require manual editing (basically combining two consecutive time ranges into one) to get the desired time intervals. This step is not mentioned in the postscript manual (manual.ps), and only hinted in the file process.doc that comes with the demo database. It could easily be overlooked. With the manual editing step being somewhat cumbersome, I exhanged arrdep with a simple matlab routine that load all database profiles (it could load the reference layer velocity as calculated by adcpsect in the nav directory instead), identifies the profiles with reference layer speeds above or below the desired threshold, and writes one time range for each profile within the desired speed bracket. The disadvantage of this simple approach are large time range files. Also, the option of codas routines like profstat or adcpsect to generate separate output for each time range would not work well, but this option is not typically used here.
With the resulting time ranges as input, profile statistics
for vertical shear of horizontal velocities, for vertical velocity, error
velocity, amplitude, spectral width, percent good,
and percent 3-beam solution were calculated (program profstat).
Note that there were about 6000 profiles for underway statistics compared
to only about 1000 for on-station conditions.
4.7.1 Vertical Shear of u, v
Mean and standard deviation of the vertical shear as measured
by the first vertical difference can be used to identify
problems in the shallowest bins due to insufficient surface blanking or
DAS processing filter problems. We did not modify
the parameters for surface blanking (4 meters), and
the direct commands for filter control (B009001) and for ping-to-ping filtertracking
(E0004020099) that were already set prior to our cruise. Although mean
shear values were well within what I have seen for other datasets (e.g.,
Bahr and Joyce, 1997), both zonal and meridional shear showed somewhat
high values for shallow bins. T. Chereskin had used 12 meter blanking
previously, although installation modifications were supposed to eliminate
the problem that prompted her to do so. I have seen the amplitude threshold
for changing the processing filter bandwidth by a factor of two set to
80 (B008001) on other cruises, which would cause the change to occur somewhat
farther down in the profile. A detailed description of the DAS direct
commands can be found in the RDI manual (RDI, 1991), and
more information on processing filter issues are given in Chereskin et
al., 1989.
4.7.2 Vertical and Error Velocity
The 4-beam Janus configuration used by RD Instruments provides two independent estimates of vertical velocity, w. The average of these is recorded as vertical velocity, and cos(30 degrees)/2 (=0.433) times the difference between the two estimates is recordeds as error velocity, e. Since the true vertical velocity in the ocean is usually very small, particularly when temporarily and spatially averaged, both w and e often indicate measurement error or flow disturbances.
Below the top few bins, the depth-averaged vertical velocity when the ship is underway is essentially a measure of the fore-aft tilt of the "vertical" axis of the transducer. This tilt can arise through misalignment of the transducer installation, changes in trim of the ship as water and fuel are consumed, and, over the very short term, pitch. Like for horizontal misalignments, vertical velocity errors are proportional to ship's speed, with a one degree tilt producing a signal of about 1.7% of the ship's speed. For the Revelle's cruising speed of about 4m/s, the average vertical velocity of less than 1 cm/s of 0.14 degrees would correspond to a tilt aft (the bow was high). Note, however, that mean w was smaller than one standard deviation.
Near the surface, the underway vertical velocity w is large and negative, decreasing exponentially over the top 50 meters. On station, w is small and negative. A w profile of this shape is typically observed for ship-mounted ADCP's, and though the cause has not definitely been determined, it is suspected to be related to flow disturbances around the ship's hull. The magnitude of -10cm/s near the surface was also reported for datasets from the RV Thompson (Flagg, 1995; Bahr and Joyce, 1997). Standard deviation of w was remarkably low at depth, reflecting the generally very good vertical extend of the profiles. The unusual peak at shallow bins was likely related to the anomalous velocity features during station departures described in the editing section.
Depth-averaged error velocity when the ship is underway
may indicate misalignment of the transducer elements
relative to each other. Short-term increases in error velocity from on-station
periods could be caused by a combination of vertical shear of horizontal
velocities and ship's tilt (Bahr 1990, unpublished
manuscript). For the JES2 cruise, both underway and on-station error velocities
were small. Again, the profiles were similar to those from the P10 cruise
on the R/V Thompson (Bahr and Joyce, 1997), although values were slightly
larger by about 75%. The shallow peak around bin 7, particularly for on-station
std, was stronger here. Similarly to shallow w, it was likely related to
the anomalous velocity features during station departure described in the
editing section.
4.7.3 Amplitude (AGC) and Spectral Width
AGC, short for amplitude gain control, corresponds to the depth-varying amplification used by the ADCP profiler to maintain a constant signal level for all vertical bins. It is generally used as a measure of signal strength. Underway AGC levels are often elevated for the bottom-most bins, indicating a higher noise floor due to ship' propeller noise etc. This is often accompanied by a decrease in shallow AGC, suggesting that the effective signal strength is reduced simultaneously. For this cruise, underway AGC was only very slightly smaller at the surface, and basically overlapped the on-station profile at depth (compare with, e.g., Bahr et al. 1990).
Spectral width was of particular interested here because
of its potential as an indicator for ringing. Teri Chereskin indicated
in her email that underway spectral width for beams 3 and 4 (for and aft
looking beams) would be elevated by ringing. Plotted here, however, is
only the beam averaged spectral width. Although the profiles show a surface
spike, followed by somewhat enlarged values for the upper 15 bins, they
are essentially identical for underway and on-station data. In fact, the
surface spike is larger in the on-station profile.
4.7.4 Percent Good, and 3-Beam Solution
Percent good gives percentage of pings in an ensemble that were considered good pings and were used for the ensemble average. It is used by many of the CODAS data access routines as a quality criterion, with 30% being a typical threshold for accepting data. Typical percent good profiles are highest over some bin range near the surface, then start a more or less linear decrease at some depth. This basic profile was also observed here, although values were slightly reduced ( and std elevated) for on-station bin 1. On many ships, underway data may reduced percent good returns due to ship's noise etc, but underway and on station percentages were remarkably similar here. This again indicates the good characteristics of the R/V Revelle as an ADCP platform.
Only three of the four beams of the ADCP are necessary to compute the three velocity components. All four are normally used when available. When data from only three beams are available or acceptable (on any given ping or bin), the DAS will optionally use the three-beam solution if it is "turned on" in the DAS's start.cnf. For each depth bin, percent-3-beam is then the percentage of pings in an ensemble for which the 3-beam solution was used. Following a typical profile, the percentage was vanishing at shallow to mid depths, and then increased with depth when not all four beams dropped out at the same depth. Again, underway and on station data were very similar. Percent-3-beam was relatively high for bin 1, corresponding to the drop in percent good for this bin.
4.7.5 Summary
The ADCP data quality in general was high for this cruise. The quality profiles were in many regards similar to those from the R/V Thompson, a sister ship of the Revelle. I did not observe the features that I understand to be related to a ringing problem, but my experience with this problem is limited. The shallowest bins, most notatably bin 1, showed elevated values in mean shear, spectral width, 3-beam solution, and a drop in percent good. To my puzzlement, these features are more pronounced in the on-station profiles.
return to the table
of contents
As an example ADCP product, vector maps are shown for a radiator survey that spanned the subpolar front, and its repeat a few days later. The were generated with the CODAS routines timegrid, adcpsect and vector.
As for contour plots, ADCP time ranges need to be generated as the first step. One may produce a list of time ranges that correspond to a geographical grid superimposed onto the cruise track. In the example shown here, the ship towed SeaSoar at nearly constant speed of 8 knots, and simple 15-minute time time ranges were used. Each plot vector was calculated by averaging in time as well over the depth intervals listed in the plot subtitles. A discussion of the velocity features is reserved for later publications.
Radiator 1, shallow levels
Radiator 1, deep levels
Radiator 1 repeat, shallow
levels
Radiator 1 repeat, deep
levels.
return to the table
of contents
To provide easy database access to non-CODAS users, all zonal and meridional velocity profile data were extracted from the database and saved in matlab format (program reference_uv.m). As a first step, the CODAS editing routines were used to extract all profiles into the matlab workspace. At this stage, profile editing parameters are contained in separate variables, while the corresponding velocity bins may still contain the original data. These bins were explicitely changed to nan's
In addition, Craig Lee had requested that the profile time be changed. Under CODAS, the end time of the ensemble average is used as profile time, while Dr. Lee preferred the center time. For the three-minute profiles used here, the profile time was advanced by 1.5 minutes, and the ship's position was interpolated onto the new line (program move_time.m).
return to the table
of contents
Special thanks go to Eric Firing and Jules Hummon from
the University of Hawaii for their ongoing support of the CODAS software
package, and for answering ADCP-related questions. Large portions of the
general CODAS descriptions follows very closely writings of Dr. Firing,
in particular opmeth.ps. Teri Chereskin from Scripps kindly provided valuable
information on the transducer installation, and ADCP performance in general.
The assistance of the Revelle's computer tech Mark Silver during the data
collection is gratefully acknowledged. This work was supported by the ONR
grant N00014-98-10369.
Bahr, F., 1990. On the relation between vertical shear
and error velocity at 0N, 165E on US-
PRC cruise #5. Unpublished manuscript, 40 pp.
Bahr, F., E. Firing, and S.-N. Jiang, 1990. Acoustic Doppler
current profiling in the western
Pacific during the US-PRC TOGA cruises 5 and 6. Data
report No. 007 from the Joint Institute
for Marine and Atmospheric Research, University of Hawaii.
161 pp.
Bahr and Joyce, 1997. Acoustic Doppler Current Profiling in the Western Pacific during the WOCE P10 Cruise, November / December 1993. Woods Hole Oceanographic Institution Technical Report No WHOI-97-04. 125 pp.
Blackman, R. B. and J. W. Tukey, 1959. The measurement
of power spectra. Dover, New York,
190 pp.
Bowditch, N., 1977: American Practical Navigator. Vol.
1. Defense Mapping Agency
Hydrographic Center, 1386 pp.
Chereskin, T. K., E. Firing, and J. A. Gast, 1989. On
identifying and screening filter skew and
noise bias in acoustic Doppler current profiler measurements.
J. Atmos. Oceanic. Technol., 6,
1040-1054.
Firing, E., 1991. Acoustic Doppler Current Profiling Measurements
and Navigation. Part of
WOCE Hydrographic Operations and Methods. Available via
anonymous ftp from
noio.soest.hawaii.edu, directory pub/codas3, file opmeth.ps.
Firing, E., 1998. Documentation file to the userexit program ue4.exe. Available via anonymous ftp from noio.soest.hawaii.edu, directory pub/userexit, file ue4.doc.
Flagg, C. N., and Y. Shi, 1995. Acoustic Doppler Current
Profiling from the JGOFS Arabian Sea
Cruises Aboard the RV T. G. Thompson. Brookhaven National
Laboratory Data Report, BNL-
61633, 153pp.
Griffith, G., 1994: Using 3DF GPS Heading for Improving
Underway ADCP Data. J. Atmos.
Oceanic Technol., Vol 11, 1135-1143.
Joyce, T.M., 1989. On in situ "calibration" of shipboard
ADCPs. J. Atmos. Oceanic Technol., 6,
169--172.
King, B. A., and E. B. Cooper, 1993. Comparison of ship's
heading determined from an array of
GPS antennas with heading from conventional gyrocompass
measurements. Deep-Sea Res., Vol.
40, No. 11/12, pp. 2207-2216.
Pollard, R. and J. Read, 1989. A method for calibrating
shipmounted Acoustic Doppler Profilers,
and the limitations of gyro compasses. J. Atmos. Oceanic
Technol., 6, 859-865.
RD Instruments, 1991. Vessel-Mounted Acoustic Doppler
Current Profiler (VM-ADCP)
Technical Manual. Available from RD Instruments, 9855
Businesspark Ave., San Diego, CA
92131.
Wilson, D., and A. Leetmaa, 1988. Acoustic Doppler current
profiling in the equatorial Pacific in
1989. J. Geophys. Res., 93, 13,947-13,966.
return to the table
of contents
Appendix A: The ADCP Configuration Files
1. The startup configuration file start.cnf
for RD Instrument's data
acquisition software (DAS) that was used during JES2.
2) The userexit program ue4.exe requires a configuration
file called ue4.cnf.
Appendix B: The UH ADCP data processing system
[Reprint of Appendix B from "WOCE Hydrographic Operations
and Methods: Acoustic Doppler
Current Profiling Measurements and Navigation." by
E. Firing, 1991. The full document is
available via anonymous ftp from noio.soest.hawaii.edu,
directory pub/codas3, file opmeth.ps.]
The University of Hawaii ADCP data processing system has
been developed and used over
several years. It has been used by several groups in
addition to mine to process more than two
ship-years of ADCP data. Some of this processing has
been done at sea in near real time by
people with no more than a few hours of training by my
group. However, this required
considerable time and effort by the new users; the system
is large and its use involves many steps.
A description of the system and an example of its use
are given by Bahr et al. (1990).
The software may be obtained from me by request: telemail
to e.firing/OMNET or Internet email
to efiring@soest.hawaii.edu. The standard distribution
package includes all source code,
documentation, and a sample dataset illustrating all
stages of processing. The source code is
internally documented and external documents have been
written for many of the major
operations. These are now being assembled into a users
manual that will describe
all data processing procedures.
B.1 Hardware
The UH system is designed to run on a variety of machines
starting with a simple PC-compatible
and including VAX-VMS and most UNIX machines. The reasons
for specifying this degree of
machine independence are:
B.2 User interface
Most routines in the UH system are governed by ASCII control
files that are designed for
readability and therefore help document the processing
of each data set. All control files can
contain unlimited comments; standard sample control files
start with a comment block that
explains the parameters in the file and gives examples.
Each parameter (or list) in a control file is
preceeded by a descriptive key word, which identifies
the parameter to both the machine and the
operator. Control files for complicated routines have
optional parameters; when not needed for a
particular operation they can be omitted, shortening
and simplifying the file.
Many routines also use intermediate ASCII data files that
are also designed to be
human-readable, with headers and comments. For example,
files listing satellite fixes are edited,
both mechanically and by hand, by prefixing the character
"%" as a comment indicator to lines
with bad fixes that are to be ignored in future steps.
Additional
comments can be used to explain why a fix was deemed
bad.
One commercial program is used as part of the UH system.
Matlab (by the MathWorks,
Inc.; available for the PC, 386-PC, Sun, Vax, and several
others) provides easy plotting and
interactive calculations.
The first step in processing a new dataset with the UH
system is to run a batch file (or
UNIX script) that builds a directory tree for the new
dataset with subdirectories
for each of the processing steps. These subdirectories
are then filled automatically with example
control files and Matlab program files (``m-files'').
The operator need only
copy his raw data files into the appropriate subdirectory,
modify the sample control files as
needed, and run the processing programs.
B.3 Database
A typical one-month cruise generates about 10 Mbytes of
binary ADCP data which include many
variables, both scalars and arrays. The variables included
in a dataset can change from one cruise
to another. The size and complexity of ADCP datasets
therefore warrant the use of a database
system rather than a simple fixed file format. To fill
this need, Ramon Cabrera, Julie Ranada, and
I have developed CODAS (Common Oceanographic Data Access
System): a set of
machine-independent subroutines for the storage and retrieval
of oceanographic and other
scientific data. It is designed for maximum storage efficiency
combined with fast random or
sequential access. It is flexible enough to comfortably
accommodate data from a wide variety of
instruments, such as the Acoustic Doppler Current Profiler
(ADCP), the CTD, current meter
moorings, and pressure gauges, together with auxiliary
observations and instrument configuration
parameters.
CODAS is hierarchical. Data are organized into profiles,
each of which may consist of
several arrays (for example, one for each of three velocity
components) and other data (flags, data
collection parameters, notes, etc.) Profiles are collected
together in blocks, each of which is an
independent, self-describing unit of data. The internal
description of each variable in a block
includes the name, units, and scale factors. A profile
is located within a block via a profile
directory that is part of the block. Blocks are catalogued
in a block directory.
A CODAS database contains only two kinds of files: a set
of data block files, and a single
block directory file. The data block files are independent
units and contain all the information
required to make a block directory file. Hence, data
blocks from different sources can be
combined into a working database by running a utility
program that generates a new block
directory file.
CODAS was written in C with care taken to make it portable
among modern machines. It
has been used on IBM PC-compatibles, a VAX 750, an Alliant,
and Sun workstations. Data
blocks are normally stored in the binary format of the
machine on which they were created or are
actively being used. When moved to another machine and
assembled into a new database, they
are automatically translated to the new binary format
if necessary (as in going from a PC to a Sun,
for example).
Storage space is minimized. The user is free to use 1,
2, or 4 byte integers, floating point,
double precision, or ASCII. However, use of the most
compact format for each variable is
encouraged, because the system (optionally) automatically
converts and scales array data from
any number format to floating point when reading, and
the reverse when writing. Storage space is
allocated as needed when the data are stored; there is
no need to waste space by specifying fixed
array lengths, for example. The extensive directory structure
adds only a few percent of storage
overhead.
The premises behind the UH editing system are:
In the UH system, suspect profiles or bin ranges are identified
primarily by running a
program (``FLAG'') that tests each profile in a given
time range for several conditions and writes
an ASCII file listing cases in which user-specified thresholds
are exceeded. The variables being
checked include error velocity, the variance in the vertical
of the vertical velocity component, the
signal strength, and the second vertical difference of
each of the velocity components. Large
values of the error velocity coinciding with large second
differences in the vertical velocity
component and in at least one of the horizontal velocity
components indicate interference by
something like a hydrographic wire. On the Moana Wave,
for example, this occurs occasionally
during CTD stations, is usually confined to a few depth
bins among the top ten, and is usually
quite subtle---the horizontal velocity component glitches
are typically only 5--10 cm/s. A local
maximum of the signal amplitude indicates either a scattering
layer or the bottom, when the
bottom is deeper than about 30 m. When the bottom is
very shallow it does not cause an
amplitude maximum, but it usually leads to high variance
in the vertical velocity profile, hence our
use of this statistic.
After running the FLAG program, one normally uses Matlab
to look at sequences of
profiles ("stagger plots") that are suspect, to make
a final decision about what to edit. In many
cases the output of the FLAG program can be used with
little modification to control the
programs that modify the database; in other cases a difficult
judgement must be made.
Once the decisions have been made, editing is done on
the database. In the case of bottom
interference, the appropriate portions of the FLAG output
file are used to specify the last bin of
each profile for which velocity data will be considered
valid, and this bin number is recorded in the
database with each profile. If there is a problem in
the top depth bins, caused, for example, by
inadequate blanking interval or by ringing of the transducer
installation, then the first bin of the
profile for which the data are acceptable may be recorded
with each profile. Otherwise, by default
this is bin 1. When the velocity in individual bins is
judged bad, a file listing these bad bins is used
to control a program that sets the appropriate bits in
an array of flag bytes. (This is a recent
improvement in the system. Previously we set the actual
velocity values themselves to a bad flag
value.)
Additional editing is normally done when the data are
accessed. Typically one specifies a
percent-good criterion, and the access program flags
as bad any velocities for which the recorded
percent-good is below the threshold. We usually use 30%.
Although our editing system is quite thorough, flexible,
and effective, it can also be
confusing and difficult to use; we plan major improvements.
B.5 Calibration
Routines are available for both the bottom-track and the
acceleration method of determining the
calibration factors. For the bottom track method the
user must select the time ranges with
continuous bottom track and navigation data. An interactive
Matlab routine is then used to edit
the navigation data and write the least-squares, best-fit
calibration factors to a file. For the
acceleration calibration method, a program automatically
selects the accelerations for which GPS
data are available and calculates the calibration factor
for each acceleration. This is written to a
file along with quality statistics. This file is input
to a Matlab routine which edits, plots, and writes
out a statistical summary.
Position fixes, GPS or Transit, are automatically screened
and merged by an editing program.
Rejected fixes are simply commented in the file, so that
they can be manually reinserted if desired.
Additional manual editing is also done, in an iterative
fashion, by commenting out questionable
fixes.
Calculation of absolute velocity profiles involves the
intermediate calculation of the
absolute velocity of a reference layer (we use bins 5
to 20, about 50--170 m) in the usual way
(e.g., Kosro, 1985; Wilson and Leetmaa, 1988). Averaged
between fixes, the velocity of the
reference layer is just the difference between the velocity
of the ship over the ground, determined
from the fixes, and the velocity of the ship relative
to the reference layer, from the ADCP
profiles. This initial estimate of the reference layer
velocity, which is constant between fixes, is
then smoothed by convolution with a Blackman window function
w(t) (Blackman and Tukey,
1958) of width T,
w(t) = 0.42 - 0.5 cos(2pi t/T) + 0.08 cos(4pi t/T).
Since the function being filtered is piecewise constant,
the convolution can be evaluated efficiently
by analytic integration over each constant piece. The
choice of filter width depends on the
characteristics of the data: the quality of the fixes
and the expected amplitude and time scales of
the currents being surveyed. When GPS is good and there
are small-scale current features of
interest, T might be as short as 15 minutes. In the worst
case of poor Transit quality and no GPS,
T can be up to 12 hours.
Our method of smoothing
the reference layer velocity is probably not optimal in many
cases; its main virtue is simplicity. The biggest problem
is that it does not take into account
nonuniform motion of the ship; smoothing is done in the
time domain only. In a region of large
spatial current gradients, this guarantees errors when
the ship changes course or stops for a
station. Usually this error has little effect on the
outcome of data analysis. The problem is likely to
be worst, and hardest to fix with a simple algorithm,
when the ship reverses course in a region of
large along-track gradient of the cross-track current---for
example, when approaching a coast
along which flows a western boundary current. Time-domain
smoothing of the reference layer
velocity then causes a systematic underestimate of the
maximum speed of the current.
Estimates of reference layer velocity as a function of
time are plotted routinely (using
Matlab) in 2-day intervals along with the ship's position.
This reveals outlying fixes or intervals of
bad GPS that have to be edited out, and also helps one
choose a smoothing filter width. The plots
resulting from the final iteration of this process serve
to document some important aspects of the
ADCP data set: the spatial coverage, the quantity and
quality of position fixes, and the degree to
which major current features have been resolved by the
smoothed reference layer estimate.
The smoothed estimate of the reference layer velocity
over the ground is added to the
velocity of the ship relative to the reference layer
to give the final estimate of the ship's velocity,
which is then integrated over each interval of nearly
continuous ADCP data and fit to the
ensemble of position fixes within the interval to generate
the ship's track. The ship's position and
velocity for each profile are written back to the ADCP
database. We could add the ship's velocity
to the velocity profile and store the resulting estimated
absolute profile, but for the present we
choose instead to do this calculation as needed when
plotting and analyzing the data.
B.7 Gridding and plotting
ADCP profiles typically give velocity estimates at nominal
8-m intervals in the vertical. We use
nearby CTD profiles, when available, to correct these
depths for the difference between nominal
and true sound speed. Additionally, the profiles are
interpolated to any user-specified grid in
depth or density coordinates. The interpolation can be
done using integration to reduce aliasing
and to give an average velocity over a given layer. The
integrated velocity is also available for use
in transport calculations.
In the horizontal, one typically wants to average profiles
in latitude or longitude bins. The
approach taken by the UH system involves two steps. First,
a program searches the database to
find the time ranges corresponding to user-specified
latitude-longitude grid. Second, these time
ranges (edited or modified if necessary) are used to
control the data access and averaging process.
Additionally one may specify the use of only underway
data or only on-station data. Another
option is to calculate transport by integrating horizontally.
Standard plots for viewing the data are of two types:
vector maps and contoured sections.
For the former we use Matlab or a custom vector mapping
program. For contouring we use a
dedicated contour program. The vector and contour programs,
unlike the rest of the processing
system, have not yet been adapted and compiled on a PC;
we usually run them on a Sun
workstation with hardcopy from a Postscript printer.
