Data from an RDI ADCP is acquired using their PC-based program TRANSECT. This same program can be used to calculate the discharge for each transect, including corrections for top, bottom and end loss. However, in order to be able to study the ADCP velocity distributions in detail, we have written routines in MatLab (and IDL) to unpack and analyze the RDI data files.

• Scanning for bad runs. Before processing a calibration run, a list of bad transects is made available to the program, in an array cs20.goodtran: 1=good, 0=bad.
• Data from the UVM and stage height recorder for the calibration period are placed into structure cs20, which is appended to the run structure. A MatLab routine loadcs20.m produces a file (eg, tms4cs20.mat) with three vectors: time in days of the month, stage in m above sea level, and velocity in m/s. These data are used later in indexing.
• Unpacking and Data Conversion:
  • adswap.pro, a byte-swapping program in IDL. The raw data are converted from PC byte order to Unix byte order and re-written. (tms3001r.000 --> tms3001s.000) It should be possible at some point to consolidate this function with the next program.
  • getrun.m, MatLab script to read in a full calibration run of transect files and consolidate the data in a MatLab structure named run. (Typical file name for saving run structure: rn001142.mat, for transects 1-142.) Function rdadens.m unpacks a single ensemble (vertical column) of ADCP data; function caladens.m carries out "uncontroversial" calculations such as units conversion, subtracting bottom velocity, and averaging over vertical columns. Script initrun.m defines file names, constants and parameters.
• Velocity Averaging. When getrun.m unpacks a run of data, space considerations prevent storing every measured velocity component in memory simultaneously. So, a single velocity component is calculated and saved. At present we save the projection of the water velocity onto the channel axis, taken as 342 degrees (clockwise from north) in the ADCP reference frame (N = magnetic north). This is saved for every good vertical bin in every ensemble of every transect of the run. Afterwards, different averages of this velocity are computed. vaver1.m is called by getrun.m to calculate ensemble and transect averages of the saved velocity component. Then vaver2.m carries out a series of special averages:
  • run.vavcen: average of velocity component over the transect; a correction factor for missing top and bottom bins is applied, assuming a y^1/6 velocity profile.
  • run.vaveast and run.vavwest: average of velocity component for the unmeasured east and west ends of the transect cross-section. This is calculated by extrapolating the measured velocity distribution near the east and west ends of the transect.
  • run.vavedge = average over west and east unmeasured ends.
  • run.vavfull = average over full cross section, including estimated top, bottom, and side contributions.
  • run.vavuvm: average of velocity component over the measured bins which the UVM sound passes through. A path of variable radius is used, starting with a radius of 2 water bins, and expanding in the center of the path to the Landay radius (about 1.1 m for our frequency and pathlength).