[Note: this is an internal working document of a USGS-SFSU
collaboration. Data, analysis and results herin should not be
considered as final or accurate. Final results will be presented in
Used in the Analysis of
ADCP and UVM Data
|ORE UVM errors
|Discharge main page
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
- 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
- run.vavcen: average of velocity component over the transect;
factor for missing top and bottom bins is applied, assuming a
y1/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).