SeaSoar Data Processing
Sea of Japan / East Sea Cruise
May 19 to June 3, 1999
Blue: location of 15-minute average SeaSoar profiles
AbstractSeaSoar Data Processing
Sea of Japan / East Sea Cruise
May 19 to June 3, 1999
Blue: location of 15-minute average SeaSoar profiles
The processing of the hydrographic data collected with
the SeaSoar, a towed vehicle that samples the upper ocean between 0 and
400 meters depth, during the Sea of Japan / East Sea Experiment (JES) cruise
is described. The cruise took place onboard the R/V Roger Revelle from
May 19 to June 3, 1999, with Dr. Craig Lee as chief scientist. While many
data plots are included to illustrate the various processing issues, a
proper description of the oceanographic fields is reserved for future publications.
1. Introduction
2.
SeaSoar cruise log
3.
Sensor placement
4.
SeaSoar Data Acquisition
5. Post-Cruise
Data Processing
5.1 Calibration
5.1.1 Conductivity
5.1.2 Temperature
5.2 Pumping T/C
sensors, variable lags
5.2.1 General Comments
5.2.2 The JES2
Lag Time Series
5.3 Lueck (thermal
mass) correction
5.4
Sensor choice for final data set
5.5 Quality control
5.5.1 General comments
5.5.2 JES 2 editing
5.6 Time check
5.7 Binning
6. References
The WHOI SeaSoar group uses the Oregon State University (OSU) software for data acquisition at sea (e.g., O'Malley et. al., 1994). In post-processing, a modified version of the acquisition routine generates hourly files of 1-second ascii averages with the input of
In the following, a cruise log in the second chapter lists events that affected the data acquisition. Sensor placement onboard SeaSoar is described in chapter three. Since its make-up affects the data set described here, the data acquisition software is briefly introduced in chapter four. Chapter five, the core of this report, covers the various steps of post-cruise data processing.
return to Table of Content
This chapter does not attempt to be comprehensive log
of the cruise, but focuses on the events of specific relevance to the SeaSoar
time series, such as sensor configurations etc. It is based primarily on
the watch entries into our SeaSoar log book. All times are in GMT. A quick
overview of the data coverage/SeaSoar flight characteristics can also be
obtained from a pressure time series for the
whole cruise.
May 19, 1999
22:34
started SeaSoar data collection. Sensor configuration:
23:00 to May 20, 00:00 (file b5200000.ave)
primary temperature died (violently). During post-cruise
cal, SeaBird finds small amount of water, and minor damage to the circuitry.
I speculate that the water tight seal was perhaps compromised when the
sensor guard was exchanged to install the T/C duct. The sensor guard twists
off, and if it is too tight, the sensor end cap unscrews rather than the
guard. I hope SeaBird would modify the seal.
May 20, 1999
03:18
terminated data collection at the end of SeaSoar recovery to fix T1. Exchanged the primary temperature sensor; new T1 had the serial number 963:
In addition to exchanging T1, we took off the secondary sensor as well for checks. Apparently we did a poor job when re-installing the flow tubes. During the following deployment, S2 developed a strong hysteresis, apparently due to sharp bends in the flow tube between pump and conductivity sensor.
Initially, the wrong cal was used for T1 up to file b5202200.ave. This was fixed by post-processing during the cruise; changing the file creation dates of those files.
We added four lead bars to left (port) side of SeaSoar to reduce the large negative roll. Number of four (about 40 pounds) was determined after balancing SeaSoar on a broom handle ("Jerry was here"). Frank's notes indicate that SeaSoar flew "significantly better" during the following deployment.
Luigi removed the scoop of the bioluminescence sensor to reduce SeaSoar drag.
We re-locate to the beginning of the
line before re-deploying SeaSoar at a location very similar to the initial
deployment.
07:39
restarted data collection during SeaSoar deployment
May 21, 1999
13:01
terminated data collection during SeaSoar recovery.
We recovered SeaSoar at the eastern corner to identify
the C2 problems, and found flow tube from C2 to pump badly bend, restricting
the flow. The C1 hose was somewhat bend as well.
We added 5th lead bar on port side, to further reduce
the negative roll.
15:55
restarted data collection during SeaSoar deployment
18:12
terminated SeaSoar data collection during recovery.
We bring SeaSoar back on deck for a brief period to identify
a HiStar problem, and found that
one of the flow tubes had come off. W re-attached more
securely with a hose clamp, and re-deployed.
18:57
restarted data collection during SeaSoar deployment.
May 22, 1999
06:53
log entry by Jerry: "Fishing gear or something;
still struggling"
May 23, 1999
May 24, 1999
07:15
log entry by Jerry: " alter course to avoid oil drum"
09:21
terminated data collection during recovery.
As early as 01:46, we had noticed an occasional glitch
in SeaSoar's flight pattern with the vehicle apparently getting up-wing
currents during a dive for brief amounts of time. At first, these instances
were very rare and short, causing little interruption in the undulations.
Over time, they became more frequent, and it became clear that SeaSoar
received up-wing current even though the flight PC sent a down-wing command.
Eventually the culprit was identified as the "Bring-it-home bottle", a
watch-dog circuit that is placed between the engineering unit and the hydraulic
unit. It was incorporated into the system during our shallow-water cruises
(<100 meters water depth) to prevent SeaSoar from crashing into the
bottom in the event of telemetry loss. It is designed to send SeaSoar to
the surface with an up-wing current if it does not see a valve current
update within a set time limit. This unit, which had worked flawlessly
for a number of cruises, had a minute amount of water in it, apparently
because of a loose mecca connector.
To quickly get SeaSoar back in the water, we simply removed
the watch-dog circuit and its pressure housing, routing the valve current
from the engineering unit directly into the hydraulic unit.
11:08
restarted the data collection during SeaSoar deployment
May 25, 1999
01:40
noticed that unix acquisition machine hazel froze while
I was transferring data files to win95 PC for cd backup. Not even remote
telnet or ping could generate a response. However, all data collection
other than the HiStar, which was manually killed by a panicking operator
(fb), restarted on its own. HiStar file h144011500.mat may have a problem.
13:42
killed SeaSoar data collection during recovery. The last file was properly closed, but the deployment termination character ("Z") is not the last character in the raw data file.
We recovered SeaSoar after it became suddenly very unstable when diving. Once the vehicle was on deck, it was obvious that we had hit something very hard. SeaSoar's new stainless steel nose cone was badly bent. The HydroScat connector had been sheared off, and the instrument had flooded. SeaSoar's top tail fin was ripped off on either side. The secondary T/C pair was dangling on its cables, with the pump cable already cut.
Although the secondary sensors tested out fine, we exchange them. We also decided to not pump one pair as a safe guard against flow tube problems. The new sensors were:
Just prior to re-deployment, noticed that TC1 tubing was
not in its usual "S" shape, and showed slight kinking. This may have caused
some hysteresis during the previous deployment. [None was found for this
time period in post-processing.]
May 26, 1999
Paul Fucile opened and dried out the Hydroscat
6, but found the electronics too damaged for shipboard repair. We replaced
the stainless steel nose cone with the original yellow plastic nose cone,
and did not fly Hydroscat for the remained of the cruise. Meanwhile, the
ship occupied a CTD section.
The change to the old nose cone significantly
altered SeaSoar's flight characteristics. We did not achieve the same depth
range as before, and had to reduce speed. According to a popular speculation,
the earlier weight distribution had resulted in a heavier front end that
produced a more favorable dive pitch. At the same time, the new configuration
did not produce the large negative rolls that typically coincide with the
beginning of the steep dive phase. Although too large a roll is known to
cause an instability, sending the vehicle back to the surface, perhaps
some negative roll is required. As often, it is not clear to me what is
cause and what is effect.
May 27, 1999
04:13
restarted data collection during SeaSoar deployment
May 28, 1999
08:00
log entry by Jerry: " holding up for fishing gear; 08:03
back to normal "
May 29, 1999
10:00
log entry by Jerry: " hold for fishing gear"
14:00
log entry by Jerry: " alt flying", implying that the vehicle
was held near the surface with the Alt+F flight mode, likely to avoid fishing
gear. Note that by far not all fishing problems were entered into the log.
18:00
log entry: "zig zagging due to fish buoys"
May 30, 1999
01:50
log note by fb: "acquisition on SUN hung; comes back when
quitting tape job"
04:10
log note: "Slalom in fishing gear, go into fish mode"
05:11
log note: "go into fish mode"
22:00
log note by fb: "SeaSoar having trouble getting below
305". Jerry had entered a similar note to the margin around 13:00.
May 31, 1999
07:12
terminated data collection during SeaSoar recovery.
The fairing had sustained significant damage, likely
from fishing gear. The subsequent re-deployment became a major "fairing
party" with help from many hands.
We moved on lead weight from port to starboard to change
the roll characteristics closer to what they had been before changing the
nose cone. In particular, we tried to reduce the new positive roll (right
wing up), and perhaps trigger the negative roll that frequently coincides
with the start of the steep dive phase. We now had 4 weights on port, one
on starboard. However, this change did not make a big difference.
11:31
restarted data collection during SeaSoar deployment.
June 1, 1999
06:00
log note: "turn around to avoid fishing boats"
13:03
log note by Jerry": snagged something on dive; pitched
up and rose to about 5m. Engineering file # 135"
16:25
terminated data collection during SeaSoar recovery.
We pulled SeaSoar to sprint for the coast and a final
cross shelf section.
June 2, 1999
11:44
restart data collection during deployment.
We re-deployed SeaSoar for a short coastal section, starting
in shallow water and moving off-shore while slowly paying out cable as
we went.
14:46
terminate data collection during the final SeaSoar
recovery.
For this last deployment, we had moved
one more weight from port to starboard (3 at port, one at starboard). It
was hard to judge, however, whether this was effective: initially, in very
shallow water, SeaSoar flew very well. But soon she became very sluggish
and would not dive well. On recovery we found a large entanglement
of 1/3'' line "draped" around the vehicle - it was amazing that she flew
at all.
return to Table of Content
The primary temperature/conductivity sensor pair ("T/C pair") was mounted on the top cover and was pumped with a standard SeaBird pump. As a test of a new sensor location, the second pair was mounted on the right side of the top stabilizer fin at the aft section of SeaSoar. It was pumped during the first two thirds of the cruise. After some problems with flow restrictions in the tubing, however, we removed pump, tubing, and the T/C duct as a safety precaution again further, perhaps more catastrophic plumbing problems. The secondary sensors then relied on free flushing, similar to configurations used during the earlier Subduction and Arabian Sea deep-water experiments. The post-cruise data processing found the T/C lag time series for the secondary sensors (pumped or un-pumped) to be generally more noisy than that of the primary sensors, indicating that the top aft fin was not an optimal sensor location.
The WetLabs fluorometer and transmissometer were located at their now standard positions in SeaSoar's undercarriage, and PAR took its usual spot on SeaSoar's tail. The new WetLabs HiStar, or AC100, was placed horizontally on the right and outside of the undercarriage. Its pump was mounted with hose clamps to the instrument itself. Short tygon hoses were connected to the forward inlets of the black flow tubes that are part of the HiStar. Since the metal fittings have a tendency to come loose, they were eventually hose clamped to the undercarriage. The new HydroScat 6 from HobiLabs was mounted vertically inside SeaSoar's new stainless steel nose cone. Its sensor plane was parallel to the flow.
return to Table of Content
The data acquisition programs collect the data in two stages. For primary acquisition, the SeaBird CTD deck unit is connected via GPIB to an IBM PC running a QuickC routine that
As a second stage, a unix box listens to the serial data stream coming from the PC and
return to Table of Content
5. Post-Cruise Data Processing
With no salinity sample comparisons available for this cruise, we relied on pre- and post cruise laboratory calibrations to determine the final calibration. Although have used additional calibration information from hydrographic water samples in the past (e.g., for the Arabian Sea cruises), we found that in general only deep bottles from TS regimes with small vertical gradients provided sensor/bottle comparisons that were sufficiently accurate to be used for calibration purposes. Only few, and no deep, CTD stations were occupied during this cruise.
Both primary and secondary sensors were calibrated at SeaBird immediately immedately before and after the cruise. The primary conductivity cell, serial number 736, showed only a small drift between pre- and post-cruise calibration. When expressed in the standard way of the SeaBird calibration sheets as a linear slope correction, the correction factor was 1.000129. However, examining the difference between pre- and post-cruise calibration more closely for the range of conductivities encountered during this cruise, it may be better expressed as a constant offset of about 0.00052 S/m (corresponding to about 0.005 psu).
With no other information available, it was assumed that the drift occurred linearly in time throughout the whole cruise. This assumption was supported by a phone call to SeaBird (Rick Baumann, pers. comm. 8/99). To apply this drift, the post-processing program that produces the final 1-sec averages (fb_pipe_varlag) was modified to correct the 24 Hz conductivities as function of time. The data were processed with the pre-cruise calibration and a drift that increased linearly from 0 on day 138 (May 19) to 0.00053 on day 152 (June 2). This new modification was tested by processing 20 hourly files that spanned the duration of the cruise with the pre-cruise, the post-cruise, and the corrected pre-cruise calibration. This veryfied the temporal transition of the drift-corrected data from zero (maximum) difference relative to the pre-cruise (post-cruise) calibrated data for the beginning of the cruise to maximum (zero) difference relative to pre-cruise (post-cruise) calibrated data at the end of the cruise.
Secondary conductivity, serial number 741, also showed a small difference between pre- and post-cruise calibration, although it was slightly larger than that for primary conductivity. In contrast to 736, 741's calibration change was adequately modeled as linear function of conductivity, with a slope correction of 1.000141. For a typical conductivity value of 3.5 S/m, the drift would be 0.00049 S/m (again approximately 0.005 psu). For the final calibration, the secondary conductivities were processed with the pre-cruise calibration and a time-dependent slope correction that changed from 1 on day 138 (May 19) to 1.000141 on day 152 (June 2). [Although the final sensor selection is discussed in more detail below, it may be helpful to note here that the final data set used secondary conductivity only for the first few hours of the first day of the cruise; that initial part of the first section was subsequently reoccupied.]
It is interesting to note that both 736 and 741drifted in an unusual way, towards higher conductivities: for a given frequency (and temperature) input, i.e., for a given raw data file, the post-cruise calibration produced higher conductivities than the pre-cruise calibration. In a phone and email exchange with SeaBird, this drift was acknowledged as unusual, but given the overall calibration history of the sensors it was not deemed indicative of problems. Mr. Baumann suggested that perhaps the extensive flushing of the cells during prolonged use onboard SeaSoar may have washed out some older deposits, restoring the cell to an earlier calibration state.
A third conductivity cell, 744, was used as secondary during the latter third of the cruise. Its drift was somewhat higher (slope correction 1.000375). For that and other reasons, the sensor was not used for the final data set.
return to Table of Content
Both primary (963) and secondary (1043) temperature sensors showed a minimal drift of 0.18 and 0.30 mdeg between pre- and post-cruise calibration. The pre-cruise calibration was used for the final data set.
Initially, sensor 1033 was used as primary temperature. It failed catastrophically a few hours into the cruise. The post-cruise calibration had to be performed after sensor repairs, and could therefore not be used to identify sensor drift. Although a first order comparison between primary and secondary sensors indicate that 1033 performed well until it failed, it was not used for the final data set.
return to Table of Content
5.2 Pumping T/C sensors, variable lags
For a typical profiling Seabird CTD system, the temperature and conductivity sensors are joined together by plastic ducts, and sea water is pumped through them. For constant pumping rate, this provides a well defined time lag between the two sensors, which is compensated automatically in the Seabird deck unit by applying a 1.75 scan lag (1 scan = 1/24 second). By factory default the deck unit lags only the primary sensors; the setting for secondary sensors is zero scans. We have since modified the settings of our deck units to set both primary and secondary sensor lags to zero. Given that the typical pumping speed of the Seabird pumps (around 1 m/s according to the pump spec sheet) is significantly less than SeaSoar's speed through the water, some groups have use un-pumped T/C pairs (WHOI between 1991 and 1995, Scripps at some time), while others have pumped their sensors (OSU, WHOI for the shallow-water Primer and Globec experiments).
The SeaSoar group at Oregon State was the first to acquire and process data from pumped sensors. They found that the pump rate and thus the temporal relation between temperature and conductivity was not constant (Huyer et al, 1993). In other words, the time lag between temperature and conductivity that is applied during data processing to minimize salinity spiking or TS hysteresis became a function of time. Initially, the group observed differences between SeaSoar data from ascending and descending profiles, which were attributed to dynamic pressure changes influencing the pumps. To address this problem, software was developed that calculated and applied time varying lags. Once the lag time series were available, longer period drifts were also observed. They could be due to a slow build-up of restrictions in the plumbing, perhaps a hardening of the tygon tubing etc. We were fortunate in that the OSU group not only shared their experiences, but also made their software available to us.
The steps to calculate T/S lag time series include
return to Table of Content
5.2.2
The JES2 Lag Time Series
The characteristics of the JES2 lag time series may be summarized as follows:
return to Table of Content
5.3 Lueck (thermal mass) correction
Heating or cooling the water inside the conductivity cell by the conductivity sensor itself can produce a conductivity signal that, when combined with the temperature measurement that does not take this effect into account, can lead to a salinity error. This heating may occur when the conductivity probe requires a finite time to reach a new ambient temperature after going through a thermal gradient. Lueck (1990) and Lueck and Picklo (1990) have derived a two- point recursive formula to correct for the thermal mass of the conductivity cell ("Lueck effect"). The magnitude of the correction is controlled by specifying an amplitude alpha and a time constant tau. As described in their work or in Seabird's data processing reports, this effect is most easily observed as smooth overshoots or round-offs of step-like vertical structures in salinity (or density). The OSU data report from the Coastal Jet Separation experiment (Barth et al., 1996) provides a detailed description of the Lueck effect on SeaSoar data. The authors describe how the correction coefficients may change for different T/C lag values, something that had already been noted earlier (Huyer et al., 1993). As suggested by Lueck and similarly in Morrison et al. (1994), alpha and tau should be inversely proportional to the flow rate. Since the T/C lag is also inversely proportional to the flow rate, alpha and tau can be expected to be proportional to the T/C lag. Barth et al. (1994) continue to describe a technique in which the thermal lag coefficients alpha and tau are calculated by minimizing hysteresis in TS diagrams.
For our previous shallow-water cruises (GLOBEC, PRIMER), I had relied on a similar albeit more subjective approach when I plotted density and salinity profiles as well as TS diagrams for a range of Lueck coefficients. Frequently, a dive cycle would contain a portion where the up- and down profile would nearly overlap and could therefore be used to "tune" the coefficients, while they would differ wildly for other parts of the cycle due to horizontal variability. Without subjectively separating the two regimes, an algorithm that minimized TS space would not determine meaningful coefficients.
For this cruise, however, TS diagrams were "well behaved" and often displayed clearly the effect of thermal lag. I therefore followed the approach of Barth et al. (1996) and created a set of routines that
The resulting series of contour plots often indicated broad bands of minimum TS hysteresis, roughly along the shape of contours alpha=constant/tau, rather than minima for unique combinations of alpha and tau. It is not obvious from TS diagrams or density profiles which combination of alpha, tau along the broad minimum would be best; e.g., compare June 1, 13:00 for combinations with short (0.02; 2), intermediate (0.015; 5), and long (0.008, 9) tau. I settled on the intermediate combination for the following reasons:
There were significant variations in the location
of minima between the 20 contour plots of TS hysteresis. In some instances,
surface variability may have skewed the calculation of best thermal lag
coefficients towards questionable results (e.g., for
May
27, 07:00). Since the TS relation is usually tighter below the near-surface
thermocline, the calculations were repeated for data
from below 75 meters depth only. This produced larger values, which
were found to correct well for thermal
lag. Repeating the lag calculations with only deep data for the complete
set of hourly files, best alpha and tau values were in general similar
to those from the complete profiles, although often slightly larger. Relying
only on the deep calculations could be problematic as well, however, as
the example of June 1, 03:00 showed. Alpha and tau from deep TS were again
larger than those obtained from the complete profiles, but were found to
overcompensate in the mid-depth range (compare TS diagrams
with
and without Lueck correction). An intermediate
set of coefficients worked well over the whole depth range.
Best thermal lag coefficients were larger during the second day of the cruise, corresponding to larger T/C lag values during the early T/C lag drift. They stepped down to smaller numbers after the adjustment of the flow tubes that also brought the T/C lag back to their initial small values. There was some indication of slightly larger thermal lag towards the end of the cruise, again coinciding with a small increase in T/C lags. Thus final values for alpha and tau were specified as function of T/C lag:
alpha =
alpha0 + alpha1 * TC_LAG
tau
= tau0 + tau1 * TC_LAG
with
alpha0 = 0.009
alpha1 = 0.01
tau0 = 5
tau1 = 0.75
These final numbers, derived from the TS hysteresis contour plots, had been "fine tuned" by post-processing the set of 20 hourly files used earlier with small variations of alpha tau, and inspecting density profiles and TS diagrams of the processed data.
Lastly, as an interesting and potentially worrying special case, the short period of negative T/C lags contained in the May 24, 02:00 file was checked. With the above T/C lag dependence this period, where T/C lags approached -1, would essentially have no Lueck correction. Applying a standard correction of alpha=0.01 and tau=5 as a test confirmed, however, that the TS relation showed less hysteresis without Lueck than with this, actually small, correction.
With the final calibration, the time series of lags, and the Lueck correction determined, all pieces were in place to re-process the raw data and re-calculate the 1-Hz averages.
return to Table of Content
5.4 Sensor choice for final data set
The primary T/C sensor pair was selected for the final data set because
return to Table of Content
Under certain conditions, SeaSoar data can be very noisy. Problems we have encountered include
Obviously such a subjective scheme is not ideal. However, we have found few cases for which a safe automatic editing algorithm can be written, so that the subjective editing appears still to be the best route at this time. One automatic tool we do use is to typically exclude the top 1 meter (top 1 dbar) of the water column to avoid bubble problems.
return to Table of Content
In general, the JES 2 data set required little editing. Most bubble problems were edited out automatically by excluding the top one meter of the water column, although especially the rapid undulations in very shallow water during the coastal section from June 2nd left some bubble noise to be edited. Slow tow speed during recovery and deployment required some editing, but in contrast to other cruises large portions particularly of recoveries, where the hauling in of the cable adds to the tow speed, were left intact. No examples of noise around the bottom turn were observed here. Of the order of 10 or so cases of isolated salinity/density spikes were edited out. The example given here shows one of the larger amplitude spikes. In nearly all cases, only one point was affected, while one spike involved two to three points. In addition to these spikes, which originated from the conductivity cell but caused a density spike as well, there were spiky salinity profiles that were not edited. In this case, no corresponding density spikes or inversions were found. The TS relation indicated that these salinity spikes, which only appear large relative to a small mean salinity signal, were temperature compensated.
A significant number of surface turns, perhaps between three and five percent, were edited for spikes around surface turns, as shown here in an example density time series and density profile. In many cases, though, only a few points from either the ascending or the descending branch of a surface turn were edited, leaving most of the signal intact. A gradient region near the surface was not a sufficient condition to trigger these spikes, however, as this example shows (the separate color was used to confirm that lines close to each other belong to the same dive cycle, as supposed to being grouped by dive- or climb branches because of up/down hysteresis).
During the second half of the cruise, following the SeaSoar modifications after the destructive "hit" and the loss of HydroScat, the window of ship speed under which SeaSoar would fly well was much tighter. At times the vehicle could get "stuck" during the ascent, leveling off at a depth well below the surface. We were hesitant to increase the ship's speed, the usual response to such flight pattern, since it could make it more difficult to reach sufficient depth later. Instead we found that we could get SeaSoar out of this mode by providing a short period of down-wing current. This would turn the wings and straighten out the vehicle roll, after which an up-wing command would send it on towards the surface. These extended level "drags", and particularly a prolonged down-wing signal that actually sent SeaSoar for a short dive, caused some suspicious density signals (see also the density profile at 20 meters). The temperature profile in this example showed a slow drift towards higher temperatures during the hovering, followed by a short-term temperature increase around the wing maneuver. Neither the previous nor the following dive cycle showed a similar temperature signal, which was taken as evidence to edit these points. Not all climb rescues of this kind caused such problems, however. In this example, the density profile showed no inversions, and the up- and down branch of this "wing wiggle" overplotted nicely. It is somewhat suspicious that the continuing up-path was not a in line with the slow up-path before the rescue, but both fall within the envelope of profiles, and the difference could be due to horizontal variability. In this case, although points are highlighted for the example plots, none were edited out. Each of these climb rescues were examined carefully, and most cases were not edited.
As mentioned earlier, the initial SeaSoar deployment, which lasted from May 19th 19:22 to May 20 03:17, was not used for the average matlab profiles for a number of reasons. The 1-second average files were fully processed, however. As could have been anticipated from the earlier summary plots of SeaSoar's flight characteristics during this early portion of the cruise, these initial files proved to have a number of problem areas such as extensive dragging at depth and at the surface, and many flight "hick ups". They were heavily edited.
For each file, an entry in a log file indicates whether a file was edited, and gives reasons for doing so. Other general comments on the data may be included as well.
Finally, the editing provides an opportunity to get a close look at the data. A few examples of interesting, or in my eye at least, "pretty" features include the following:
The SeaSoar time is derived from the PC clock of the original acquisition PC. All PC's and unix machines are set to GPS time at the beginning of the cruise. We test and correct for PC clock drift by comparing SeaSoar time to the GPS fix time as recorded in each line of the 1- second average ascii files.
First, the difference between PC and GPS time were plotted for the whole cruise, and approximated by a linear fit (in red). While some points indicated a zero second difference at the beginning of the cruise, a PC lead of one or more seconds was found as well. Although I have not fully understood this broad range in time differences, I believe it originates at least in part at the PC acquisition program. The program attends to its various tasks over particular time intervals, rather than, for example, writing each CTD scan to disk and sending it on to the secondary acquisition routines as they arrive. The reasons for this date back to problems with overhead time for hard disk access etc. during the program development (Tim Holtt, OSU SeaSoar team, pers. comm. 1994). For all of our recent cruises, we use 48 scan intervals (two seconds) for polling the GPS serial port, writing to disk, and serial raw data transfer. Based on these considerations and on my knowledge that we carefully double-checked the PC clock against GPS time at the beginning of the cruise, I took the initial two-second mean difference to indicate correct PC clock time.
As is evident from the record, the PC clock was reset for the second and third major deployments (day 146 and 152, or May 27 and June 2, respectively). Unfortunately, no log entry marked the exact time of reset. Rather than near +2 seconds as before, the mean drift during the second major deployment started at surprisingly low numbers. However, the drift speed or slope calculated from the linear fit appeared less than one might expect based on an envelope of the PC-GPS data, and was smaller than the previous slope. Using the larger slope out towards a hypothetical clock reset time at the end of the previous deployment would provide again an approximately +2 second start time difference. The clock was also reset for the last, coastal deployment.
A time correction was applied that adjusted the linear fit of PC minus GPS time to a constant two second difference. The algorithm was checked by comparing the corrected and the original time record.
The secondary unix data acquisition program placed a time stamp with each 1-second average as well. A comparison to GPS time indicates that the unix machine's clock drifted at a similar rate as the PC clock, but with the opposite sign. The unix clock was not reset. A plot showing the comparison of PC and unix clock is included here for completeness.
return to Table of Content
For a number of applications, particularly under matlab, it may be more convenient to work with vertical profiles rather than with a continuous time series. Here, "profiles" refer to the format of a traditional hydrographic data set with one depth profile per geographic location. SeaSoar data have to be averaged in time and possibly depth to conform to such a scheme. We have experimented with different approaches: an earlier version tried to identify a complete dive cycle and produce one average profile per dive cycle. In addition to the inherent disadvantage of an irregular grid in time (since not all dive cycles take the same amount of time to complete), it proved to be difficult to address the unusual cases (aborted profiles, "hick ups" etc.) with an automated algorithm. Our current approach averages the SeaSoar data over a constant time period, in this case 15 minutes. Within each time interval, the data are pressure binned into 4 dbar bins. Data points with flag values larger than a set threshold (always used so far: 7) are excluded. A quality flag for each profile, one digit per variable, contains the maximum of the flag values encountered for each variable during the averaging interval.
Horizontal gradients in a vertically stable stratified field may lead to density inversions in the average profiles. This problem may be accentuated for an averaging scheme of fixed time length, depending on the relation of the sampling interval to the actual dive cycle length. However, one can think of scenarios where this problem would occur in a cycle-by-cycle averaging scheme as well. Since these inversions are not caused by faulty sensors or similar problems, they were not edited out here.
The time associated with each profile was based on the ideal time grid of 15 minute intervals, centered on 0, 15, 30, and 45 minutes into the hour. If data gaps existed within a time interval, the mean data time would be different from this nominal time. A text file generated during the averaging run kept a log of both times, as well as of the number of points used per interval etc. In addition, all instances in which either the two times differed by more than a minute, or for which the number of points was less than a specified threshold (900 - 55) were logged in a separate, much shorter matlab-loadable file. For this cruise, only SeaSoar deployment starts and ends resulted in any significant differences between mean and nominal times.
The very first deployment of the cruise lasted only a few hours, and was aborted when the primary temperature sensor flooded and died. For the second deployment starting May 20th, 07:39, we returned to the beginning of the west-east line and re-occupied the initial portion of this section. The primary sensors remained unchanged throughout the remainder of the cruise, and for a number of reasons were selected as the final sensor pair. With the failure of T1, secondary sensors had to be used for the data collected prior to 5/20, 07:39. Primary and secondary sensors may provide a slightly different view of the same oceanographic fields because of their separate locations onboard SeaSoar. Furthermore, SeaSoar's flight patterns were rather poor during the first few hours, resulting in a significantly higher number of noise and other data problems. For these reasons, the initial hours were not used when calculating the average profiles.
Summary plots show the 1006 average profiles of temperature,salinity, and density in groups of 50 profiles per plot. The offset between profiles is two degrees C, 0.1 psu, and 0.5 sigmatheta units, respectively.
return to Table of Content
Barth, J. A., R. O'Malley, J. Fleischbein, R. L. Smith and A. Huyer, 1996. SeaSoar and CTD observations during the Coastal Jet Separation cruise W9408A August to September 1994. College of Oceanic and Atmospheric Sciences, Oregon State University, Corvallis. Reference 96-1, Data Report 162, November 1996.
Huyer, A., P. M. Kosro, R. O'Malley and J. Fleischbein, 1993. SeaSoar and CTD observations during a COARE survey cruise, W9211C, 22 January to 22 February 1993. College of Oceanic and Atmospheric Sciences, Oregon State University, Corvallis. Reference 93-2, Data Report 154, October 1993.
Lueck, R., 1990. Thermal inertia of conductivity cells: Theory. J. Atmos. Oceanic Tech., 7, 741-755.
Lueck, R., and J. J. Picklo, 1990. Thermal interia of conductivity cells: Observations with a Sea-Bird cell. J. Atmos. Oceanic Tech., 7, 756-768.
Morrison, J., R. Andersen, N. Larson, E. D'Asaro and T. Boyd, 1994. The correction for thermal-lag effects in Sea-Bird CTD data. J. Atmos. Oceanic Tech., 11, 1151-1164.
O'Malley, R, P. M. Kosro, R. Lukas and A. Huyer, 1994. SEASOAR observations during a COARE survey cruise, W9211B, 12 December 1992 to 16 January 1993. College of Oceanic and Atmospheric Sciences, Oregon State University, Corvallis. Reference 94-2, Data Report 156, May 1994.
Sea-Bird Electronics, Inc, 1994. CTD data acquisition software SEASOFT version 4.203, 28 April 1994. SeaBird Electronics, Inc 1803 136th Place NE, Bellevue, WA 98005
