17
|
1 |
======================================================================
|
|
2 |
R E A D M E . T I M E L A G G I N G
|
|
3 |
doc: Fri Oct 19 10:08:19 2012
|
|
4 |
dlm: Fri Oct 19 12:13:59 2012
|
|
5 |
(c) 2012 A.M. Thurnherr
|
|
6 |
uE-Info: 106 0 NIL 0 0 72 3 2 8 NIL ofnI
|
|
7 |
======================================================================
|
|
8 |
|
|
9 |
=Introduction=
|
|
10 |
|
|
11 |
In order to derive velocity profiles the data from the CTD and LADCP
|
|
12 |
instruments need to be merged. This is accomplished by calculating lag
|
|
13 |
correlations between the two corresponding time series of vertical
|
|
14 |
velocities calculated from the two instruments. In this software, the
|
|
15 |
time lagging is accomplished WITHOUT regard of the clock time reported
|
|
16 |
by the instruments, i.e. the instrument clocks do not have to be
|
|
17 |
synchronized. Instead of clock time, elapsed time in seconds is used. In
|
|
18 |
case of the CTD data, an elapsed time field can be supplied by the user
|
|
19 |
(see [README.ProcessData]); in case of the LADCP data, the
|
|
20 |
"elapsed-time" field is calculated by the software. The "elapsed-time"
|
|
21 |
fields in the processing output are always consistent with the CTD
|
|
22 |
elapsed times. While the time-lagging algorithm implemented in the
|
|
23 |
software is fairly robust, it has been known to fail. Possible reasons
|
|
24 |
include:
|
|
25 |
|
|
26 |
1) CTD PRESSURE SPIKES. Significant pressure spikes must be removed
|
|
27 |
prior to processing, *without* adding or removing CTD time-series
|
|
28 |
records.
|
|
29 |
|
|
30 |
2) LACK OF SURFACE VESSEL MOTION. If there is no surface-wave motion
|
|
31 |
affecting the vessel, time lagging is much more difficult. In rare
|
|
32 |
cases, time lagging must be carried out manually (see below).
|
|
33 |
|
|
34 |
3) MISSING CTD SCANS. For SeaBird 911 systems, if the connection
|
|
35 |
between the CTD and the deck box is not clean CTD scans will be
|
|
36 |
dropped. For the software, this looks like the CTD clock running faster
|
|
37 |
than the ADCP clock. There are cases where the CTD clock appears to
|
|
38 |
have gained more than 5 seconds during a 2000m-deep cast.
|
|
39 |
|
|
40 |
4) MULTIPLE CTD FILES. When CTD acquisition is restarted during a cast,
|
|
41 |
multiple files are created. In order to process the LADCP data from such
|
|
42 |
a cast, a CTD time-series file without any missing records must be
|
|
43 |
constructed manually.
|
|
44 |
|
|
45 |
|
|
46 |
=Solving Time-Lagging Problems=
|
|
47 |
|
|
48 |
While there are several run-time options that can be used to help the
|
|
49 |
time-lagging algorithm, detailed knowledge of the algorithm is required
|
|
50 |
to understand when and how to use these options, i.e. the user is
|
|
51 |
referred to the code and comments in [LADCPproc.bestLag]. However, the
|
|
52 |
following method can always be used to solve time-lagging problems, as
|
|
53 |
long as the CTD time series does not have any gaps.
|
|
54 |
|
|
55 |
|
|
56 |
-Step 1: Produce and Plot a Combined CTD/LADCP Time-Series File-
|
|
57 |
|
|
58 |
This is accomplished by processing the data with the "-l 0" option and
|
|
59 |
using "-t <time-series file>" to produce the file. Plot the resulting
|
|
60 |
time series of CTD_w and LADCP_w in the same panel. The plot should
|
|
61 |
show immediately whether there are problems with the CTD pressure data
|
|
62 |
(spikes). Often, standard processing works after setting any bad
|
|
63 |
pressure values to nan.
|
|
64 |
|
|
65 |
|
|
66 |
-Step 2: Manually Determine an Approximate Time Lag-
|
|
67 |
|
|
68 |
Use the output file generated in step 1 to determine how many seconds
|
|
69 |
have to be added to the elapsed field when plotting LADCP_w to bring
|
|
70 |
the two time series into approximate (a few seconds accuracy)
|
|
71 |
agreement. Often, the data can now be processed normally by using "-i
|
|
72 |
<estimated lag>".
|
|
73 |
|
|
74 |
|
|
75 |
-Step 3: Manually Determine an Accurate Time Lag-
|
|
76 |
|
|
77 |
If preprocessing with the -i option still does not succeed, time lagging
|
|
78 |
must be carried out manually. If this happens, there is most likely a
|
|
79 |
serious problem with either the CTD or LADCP data that should be solved
|
|
80 |
before proceeding. This is done exactly as in step 2 but to higher
|
|
81 |
accuracy (as high as you can). Once the best lag has been determined
|
|
82 |
manually, the data can be reprocessed with the "-l <manually determined
|
|
83 |
lag>" option.
|
|
84 |
|
|
85 |
|
|
86 |
After solving any time-lagging problems the results should be checked by
|
|
87 |
creating a time-series file (with -t) during final processing and
|
|
88 |
overplotting the LADCP_w and CTD_w time series. If there is still a
|
|
89 |
visible lag between the time series time lagging was not carried out
|
|
90 |
correctly.
|
|
91 |
|
|
92 |
|
|
93 |
=Patching Together CTD Time-Series Files=
|
|
94 |
|
|
95 |
The LADCP processing software requires the CTD data to be supplied as a
|
|
96 |
single time series file with a constant sampling interval. When CTD
|
|
97 |
data acquisition is restarted during a cast, multiple files are
|
|
98 |
produced. The resulting files cannot simply be pasted together because
|
|
99 |
the resulting time series would have gaps. The only way to solve this
|
|
100 |
problem is to determine separate time lags for each of the CTD files
|
|
101 |
manually (using the method described above). The difference between the
|
|
102 |
resulting time lags is equal to the length of the gap between the two
|
|
103 |
files. The user can now create a dummy (all fields set to nan) CTD file
|
|
104 |
with required number of records that must be added between the CTD
|
|
105 |
files to create a single continuous regularly-space time series.
|
|
106 |
Fractional seconds can be ignored.
|