Metadata Report for BODC Series Reference Number 624278

• Metadata Summary

• Problem Reports

• Data Access Policy

• Narrative Documents

• Project Information

• Data Activity or Cruise Information

• Fixed Station Information

• BODC Quality Flags

• SeaDataNet Quality Flags

Metadata Summary

Problem Reports

There appears to be a discrepancy between ADCP bin depths in the originators data files and the information provided in the cruise report.

From the information in the files, bin depths range between 16 and 412 m. From the cruise report, the instrument was 5 m below sea surface, the blank beyond transmit value was 4 m and the bins were 4 m deep. Assuming that bin depth is taken at the center of each bin relative to the sea surface then the depth of the first bin can be calculated as the sum of the instrument location offset in the hull, plus the blank beyond transmit, plus half a bin. Using data listed in the cruise report this gives: 5+4+2= 11m.

The data have been transferred to BODC format without alteration and potentially the bin references are all 5m too deep.

RRS Discovery 258 VMADCP Data Quality

Data originator comments

The following are data originators comments, on both the 75 and 150kHz VMADCPs, adapted from the D258 cruise report.

The on-station data tend to be the best quality ADCP data, penetrating deepest into the water column. The on-station data for the CTD stations were selected and averaged into u and v profiles for each ADCP. The data were merged together and the differences in u and v calculated (75 minus 150). As on Discovery 253, the results were very encouraging, suggesting the ADCPs agreed within the expected noise level of the instruments:

U (east) Mean = 0.129 cm/s, sd = 1.973 (n = 1356)
V (north) Mean = 0.167 cm/s, sd = 2.161 (n = 1356)

However, it was clear from the %good values that the 150 kHz data appeared considerably poorer. This may be a result of the 4 m bin length chosen for the 150 kHz setup and sparse winter populations of zooplankton. Certainly the %good contour plots look like they show biological layering, but only a thorough investigation of the amplitude backscatter will confirm this.

Depth of penetration

The main potential advantage of the 75 kHz ADCP is that the lower frequency means greater depth penetration, though at reduced vertical resolution (16m bins vs 4m). During Discovery 258 the 75kHz ADCP managed to reach 700-750m on station, and 400-500 m steaming. In contrast, typical maximum depths for the 150 kHz are 350-400 m under the same conditions. It is noticeable though that the 75 kHz depth penetration during steaming suffered very readily with the onset of anything other than calm conditions. It was postulated on Discovery 253 that the forward well is more prone to contamination by bubbles than the aft well, and if the 75 kHz ADCP is to become the standard ADCP for Discovery it may be appropriate to move the 75 kHz to the aft well. However, the underway data during cruise 258 were generally poor as a result of poor weather and high steaming speeds when weather windows occasionally permitted them. The mid-depth spiking in the 75 kHz data at ~330 m, discussed on Discovery 253, was not obvious during cruise 258, however the small amount of good underway data available may make this observation unreliable.

BODC Quality control

Post transfer to BODC internal format (QXF) the data were manually screened using BODC XERPLO visualisation and quality control software. The data were viewed as a continuous time series with the 75 and 150 kHz data streams displayed simultaneously. Visual inspection confirmed the originators findings in that

• the on station data tend to be the best quality
• data quality suffers greatly during poor weather conditions and/or high steaming speeds (>2m/s)

in addition

• notable spikes occur in both series when the ship is maneuvering on and off station
• when on station the 150 kHz data show less variability c.f. the 75kHz instrument

Because of the poor quality of the underway data no attempt has been made at quality control. Users are advised to use these data with caution. Attention was restricted to the periods when the vessel was on station. Data in these periods all data appeared to be within acceptable limits and without acceptable justification no flagging was attempted.

One period of note is 29/11/2001 06:30 (approx.) to 17:00, where the 75 and 150 kHz E-W velocity signals diverge in all bins. The difference is approximately 100cm/s when the 75kHz trace ends. As expected the two series initially overlay one another and the 150 kHz series remains changes little while the eastward component of 75 khz series grows steadily until the difference is 100cm/s. It was not obvious why the series diverge and without further investigation not possible to ascertain which series is correct.

Data Access Policy

Open Data supplied by Natural Environment Research Council (NERC)

You must always use the following attribution statement to acknowledge the source of the information: "Contains data supplied by Natural Environment Research Council."

Narrative Documents

RD Instruments- Ocean Surveyor 150kHz Vessel mounted ADCP.

¹ Ranges at 1 to 5 knots ship speed are typical and vary with situation.
² Single-ping standard deviation.
³ User's choice of depth cell size is not limited to the typical values specified.

Profile Parameters

• Velocity long-term accuracy (typical): ±1.0%, ±0.5cm/s
• Velocity range: -5 to 9m/s
• # of depth cells: 1 - 128
• Max ping rate: 1.5

Bottom Track

Maximum altitude (precision <2cm/s): 600m

Echo Intensity Profile

Dynamic range: 80dB
Precision: ±1.5dB

Transducer & Hardware

Beam angle: 30°
Configuration: 4-beam phased array
Communications: RS-232 or RS-422 hex-ASCII or binary output at 1200 - 115,200 baud
Output power: 1000W

Standard Sensors

Temperature (mounted on transducer)

• Range: -5° to 45°C
• Precision: ±0.1°C
• Resolution: 0.03°

Environmental

Operating temperature: -5° to 40°C (-5° to 45°C)*
Storage temperature: -30° to 50°C (-30° to 60°C)*

*later instruments have greater range.

Web Page

Further details can be found in the manufacturer's website or in the specification sheet.

RRS Discovery 258 150kHz VMADCP processing

Introduction

The following is adapted from the D258 Cruise report.

Two RDI vessel-mounted Acoustic Doppler Current Profilers (VM-ADCPs) were operated on Discovery 258; the 150 kHz VM-ADCP and a new 75 kHz Phased Array instrument (Ocean Surveyor) that had been fitted immediately prior to Discovery 253 (FISHES; May/June 2001).

The 150 kHz ADCP was mounted in the hull 1.75 m to port of the keel, 33 m aft of the bow at the waterline and at an approximate depth of 5 m. The 75 kHz ADCP was also mounted in a second well in the hull, but 4.15 m forward and 2.5 m to starboard of the 150 kHz well. The following section describes the operation and data processing paths for the 150kHz ADCP.

Narrative

The 150 kHz RDI ADCP was logged using IBM Data Acquisition Software (DAS) version 2.48 with profiler software 17.20. The instrument was configured to sample over 120 second intervals using 100 bins of 4 m thickness, pulse length 4 m and a blank beyond transmit of 4m. The higher vertical resolution was used to better support the remote detection of zooplankton patchiness. Early in leg 1 and during the steam into and out of Reykjavik the ADCP was switched to bottom and water track mode over shallow ground to enable calibration. The two vessel mounted ADCPs were configured to synchronise their pings over the ensemble period, with the 150khz as the "master" and the 75khz as the "slave", as recommended by RDI. The result is that each ADCP has only 40 water track pings in the 2 minute period. Spot gyro heading data were fed into the transducer deck unit where they were incorporated into the individual ping profiles to correct the velocities to earth co-ordinates before being reduced to a 2 minute ensemble.

The main difference between the 150 ADCP on Discovery 253/258 and previous cruises was that it had been refitted in dry dock prior to Discovery 253 and given an offset of 45° on the advice of RDI. This offset was accounted for in the DAS software on Discovery 253, however it was missed out of the setup file at the beginning of 258. This is not a problem in itself, as the user's calibration process will correct for the orientation, however, it could be alarming to derive a tan phi = 0(1) if unaware of the offset. The other major advance was that the ADCP PC clock has been synchronised with the ships master clock, so removing the tedious need for logging the drift of the PC clock and correcting for it in the processing (old adpexec1). As good practice, however, a check on the ADCP clock time was still made every 24 hr, as was a record of the ADCP electronics temperature.

The ADCP data were logged continually by the level C computer. From there they were transferred once a day to the Pstar data structure and processed using standard processing scripts in Pstar; which are presented below. Until Julian day 313 (9 Nov), we experienced communication problems between the ADCP PC and the level C. Three times a day, the data stream would hang and the adcppro level C process would have to be restarted. As there is no warning alarm, this frequently went unnoticed at the very beginning of the cruise leading to quite large gaps (up to a few hr duration) in the data logging. A strange artifact of this was that just the top (16 m) bin of the ADCP data would be logged for a particular time-step associated with each hanging of the adcppro level C process. Thus some manual editing was required to obtain a gridded data file of 100 bin profiles. In addition, one in every three dropouts each day would log bottom track info associated with the single bin data and thus this also had to be edited out of the bottom track file - these edits were made with mlist and pcopya. The problem was solved during the evening of Julian day 313. The header file log on the level C was write protected, and although we do not subsequently use this header, each time the PC began a new ping data file the communications fell over when it tried to write a new header.

Within a few days of the beginning of the cruise, it was clear that the quality of the 150 kHz data was deteriorating rapidly, with the maximum value of 100% good return echoes per 2 min ensemble in a 24 hr period dropping to less than 90%. This was indicative of air in the transducer well. In response to our queries, John Wynar, Bob Keogh and Steve Whittle investigated the problem. The quarter turn valve in the bleed pipe was open; however on closer inspection, following the removal of the bleed pipe, the valve was found to be blocked by scale build-up. The blockage was removed but did not solve the problem as the bleed pipe itself was blocked on the air side of the valve. This was more difficult to clear as around 8 cm of the flexible pipe was scaled up. However, following drilling and poking this too was cleared. This immediately solved the problem with ADCP data quality and was completed by the afternoon of Julian day 313. Subsequently Bob and Steve, also investigated the gate valve in the large bore steel stand pipe to which the aforementioned bleed pipe connects.

A calibration of the 150 kHz ADCP was achieved using the limited high quality bottom tracking data available from our departure across the southern Hebridean shelf. As a result of the limited amount of good bottom track data available but the very low positional scatter in the Trimble GPS 4000 positions, as determined earlier, we experimented with a calibration based on standard two min ensemble profiles rather than the usual 10 or 20 min averages. The data used were between 306 19:00:41 and 306 22:08:42 After removing outliers of 2 standard deviations, this resulted in tan phi = 1.1434 (± s.d. = 0.0177),phi = 48.82° and A = 1.0005 (± s.d. = 0.0050). These compared well with the values obtained during Discovery 253 (phi = 3.814° and A = 0.9966), particularly as it was suspected that the cos theta term in the derivation of A (normally negligibly different from 1) was missed out and in fact A should have been 0.9988. As a compromise we used phi= 48.82° and A = 1.0000 in adpexec3.

A power cut on Julian day 340 (6 Dec) at around 1600 corrupted some software files on the 150 kHz PC and logging was eventually restarted at 1940 after the software was reloaded. In fact the run into Reykjavik meant the ADCPs were switched off from midnight on JD 340 to 1154 on JD 341. On JD 344 the PC gave up the ghost and was replaced by another PC. The hard disk on the replacement PC was small and so data were logged only to the Level B, not the PC. The date on the new PC was set incorrectly and so the time stamp of the Level B data was 24 hours ahead of true time. The Pstar files were thus corrected to true time using pcalib after the datapup process in adpexec0 and before merging with navigation and header data.

SOC PEXEC processing

adpexec0 transferred data from the RVS level C "adcp" data stream to SOC Pstar format. The data were split into two; "gridded" depth dependent data were placed into "adp" files while "non-gridded" depth independent data were placed into "bot" files. Velocities were scaled to cm/s and amplitude by 0.42 to db. Nominal edits were made on all the velocity data to remove both bad data and to change the DAS defined absent data value to the Pstar value. The depth of each bin was determined from the user-supplied information. Output files: adp258##, bot258##

adpexec2 this merged the ADCP data (both files) with the Ashtech a-ghdg created by ashexec2. The ADCP velocities were converted to speed and direction so that the heading correction could be applied and then returned to east and north. Note the renaming and ordering of variables. Output files: adp258##.true, bot258##.true.

adpexec3 applied the misalignment angle, phi, and scaling factor, A, to both ADCP files. The ADCP data were edited to delete all velocities where the percent good variable was 25% or less. Again, variables were renamed and re-ordered to preserve the original raw data. Output files: adp258##.cal, bot258##.cal.

adpexec4 merged the ADCP data (both files) with the Trimble GPS 4000 navigation file (gp42581) created by gp4exec0 and the bestnav navigation file (abnv2581) created by navexec0. Ship's velocity was calculated from 2 minute spot positions taken from the gp42581 file and applied to the ADCP velocities. The end product is the absolute velocity of the water. The time base of the ADCP profiles was then shifted to the centre of the 2 minute ensemble by subtracting 60 seconds and new positions were taken from abnv2581, this last stage was not done in the processing scripts on Discovery 253. Output files: adp258##.abs, bot258##.abs.

surexec0 data read into Pstar format from RDI binary file (psurvey, new program written on Discovery 253 by S Alderson). Water track velocities written into 'sur' file, bottom track into 'sbt' files if in bottom track mode. Velocities were scaled to cm/s and amplitude by 0.45 to db. The time variable was corrected to GPS time by combining the PC clock time and the PC-GPS offset. The depth of each bin was determined from the user-supplied information. Output files: sur258##.raw, sbt258##.raw.

surexec1 data edited according to status flags (flag of 1 indicated bad data). Velocity data replaced with absent data if variable '2+bmbad' was greater than 25% (% of pings where >1 beam bad therefore no velocity computed). Time of ensemble moved to the end of the ensemble period (120 sec added with pcalib). Output files: sur258##, sbt258##.

surexec2 this merged the ADCP data (both files) with the Ashtech a-ghdg created by ashexec2. The ADCP velocities were converted to speed and direction so that the heading correction could be applied and then returned to east and north. Note the renaming and ordering of variables. Output files: sur258##.true, sbt258##.true.

surexec3 applied the misalignment angle, phi, and scaling factor, A, to both files. Variables were renamed and re-ordered to preserve the original raw data. Output files: sur258##.cal, sbt258##.cal.

surexec4 merged the ADCP data (both files) with the Trimble GPS 4000 navigation file (gp42581) created by gp4exec0 and the bestnav navigation file (abnv2581) created by navexec0. Ship's velocity was calculated from 2 minute spot positions taken from the gp42581 file and applied to the ADCP velocities. The end product is the absolute velocity of the water. The time base of the ADCP profiles was then shifted to the centre of the 2 minute ensemble by subtracting 60 seconds and new positions were taken from abnv2581, this last stage was not done in the processing scripts on Discovery 253. Output files: sur258##.abs, sbt258##.abs.

BODC processing

The originators files used for transfer were SOC Pstar format calibrated, gridded depth dependent data, filenames adp258##.abs. Where ## is the number of the day file

Transfer mapping

The varibles within the Pstar files where mapped to BODC parameter codes

Pstar variables present in the files but not mapped fro transfer included: evelcal, nvelcal, ve, vn, a-ghdg and distrun. These where excluded on the grounds that that they were either intermediated processing infomation or available elsewhere (i.e. underway navigation)

Transfer

The data were trnasferred to QXF format, a BODC-defined subset of NetCDF and BODC's format for 2 dimensionsal datacycle storage. Pstar null data were set to the appropriate absent data values for the code in the BODC parameter dictionary.

Screening

Each data channel was inspected on a graphics workstation and spikes or periods of dubious data were flagged. Whenever possible, comparative screening checks between channels were employed.

RRS Discovery 258 Navigation

The following is adapted from the Discovery 258 cruise report.

Discovery's best determined position was calculated by the process "bestnav". The main data source was a newly purchased Ashtech G12 positioning system. Thus the GPS Trimble 4000 system, used for most recent cruises was recorded separately. In fact the Ashtech G12 electronics board replaced the Sea Star Mark III Differential GPS system and continued to provide differential corrections to the GPS 4000 system. Thus an examination of positional accuracy, whilst tied up alongside in Govan and Reykjavik, showed that the corrected GPS 4000 system provided higher positional accuracy than the new Ashtech G12 system (calculated with Pstar program gpsrms).

However, results from all three of these systems (Table 1, below) indicate sufficient precision to enable a calculation of ship's velocities to better than 1 cms^-1, and therefore below the instrumental limits of the RDI ADCP systems.

Table 1. Comparison of port-based positional accuracy determinations

If there were gaps in the G12 data, the bestnav process used other inputs as necessary. These were turned to in the strict preference order: GPS Trimble 4000 data, GPS Ashtech 3D, GPS Glonass (which uses a combination of Russian and American satellite networks). Or, as a last resort, if no GPS was available the Chernikeef electo-magnetic log velocity data and gyro heading were used to dead-reckon the ship's position.

Data were transferred daily from the Level C bestnav stream to the Pstar absolute navigation files, abnv2581 (leg 1) and abnv2582 (leg 2) The G12, gps-4000, gps_glos and gyro (gyronmea) data streams were also transferred daily. Processing scripts nav-, gyro-, gps-exec0 etc are summarized below

Heading

The ship's attitude was determined every second with the ultra short baseline 3D GPS Ashtech ADU2 navigation system. Configuration settings from previous calibrations (Trials cruise in April 2001) were used throughout the cruise. Four antenna, two on the boat deck, two on the bridge top, measured the phase difference between incoming satellite signals from which the ship's heading, pitch and roll were determined. The data were used to calibrate the gyro heading information using the ashexecs listed below

Ashtech 3D GPS coverage was generally good. Dropouts occurred several times; but on only one occasion was it necessary to reset the Ashtech Unit in the Comms Room. Gaps over 1 min in the data stream are listed in table 2.

Table 2. Gaps in Ashtech 3D GPS coverage

SOC PEXEC navigation processing

The text in bold refers to SOC PEXEC processing scripts. Details of the PEXEC data processing format (Pstar) and programs can be found at:
http://www.soc.soton.ac.uk/JRD/PEXEC/pexec.html

navexec0 transferred data from the RVS bestnav stream to Pstar, calculated the ships velocity, appended onto the absolute (master) navigation file and calculated the distance run from the start of the master file. Output: abnv2581 and abnv2582.

gyroexec0 transferred data from the RVS gyronmea stream to Pstar, a nominal edit was made for directions between 0-360° before the file was appended to daily master files.

gp4exec0 transferred data from the RVS gps_4000 stream to Pstar, edited out pdop (position dilution of precision) greater than 5 and appended the new 24 hour file to master files gp42581 and gp2582.

glosexec0 this was identical to gp4exec0 but transferred the RVS gps_glos data stream to Pstar in master files gls2581 and gls2582.

gpsexec0 this was identical to gp4exec0 but transferred the RVS gps_g12 data stream to Pstar in master files gps2581 and gps2582.

ashexec0 transferred data from the RVS gps_ash stream to Pstar.

ashexec1 merged the Ashtech data from ashexec0 with the gyro data from gyroexec0 and calculated the difference in headings (hdg and gyroHdg); ashtech-gyro (a-ghdg) (daily files).

ashexec2 edited the data from ashexec1 using the following criteria:

• heading 0 < hdg < 360 (degrees)
• pitch -5 < pitch < 5 (degrees)
• roll -7 < roll < 7 (degrees)
• attitude flag -0.5 < attf < 0.5
• measurement RMS error 0.00001 < mrms < 0.01
• baseline RMS error 0.00001 < brms < 0.1
• ashtech-gyro heading -10 < a-ghdg < 10 (degrees)

The heading difference (a-ghdg) was then filtered with a running mean based on 5 data cycles and a maximum difference between median and data of 1 degree. The data were then averaged to 2 minutes and further edited for:

-2 < pitch <2
0 < mrms < 0.004
-10 < a-ghdg < 10

The 2 minute averages were merged with the gyro data files to obtain spot gyro values. The ships velocity was calculated from position and time, and converted to speed and direction. The resulting heading difference should be a smoothly varying trace that can be merged with ADCP data to correct the gyro heading. do.plotash was the script used to produce diagnostic plots to check this. During ship manoeuvres, bad weather or around data gaps, there were spikes which were edited out manually (plxyed).

ashexec3 appended daily Ashtech files to a master file (ash258smt.ave) after removing any overlapping time steps. The master file was subsequently used in VMADCP and surfmet data processing.

Project Information

Marine Productivity programme (MarProd)

The Marine Productivity programme (MarProd) was a Thematic Programme of the Natural Environment Research Council. It was funded for a period of five years starting in 2000. Its main goal was "to develop coupled modelling and observation systems for the pelagic ecosystem, with emphasis on physical factors affecting zooplankton dynamics" with the following specific objectives:

• To identify the dominant spatial and temporal scales of physical parameters and zooplankton population dynamics, by observation, modelling and retrospective analysis

• To parameterise the critical processes governing zooplankton dynamics by observations and experiments

• To construct and validate spatially explicit models of zooplankton and their food and predators, capable of resolving short term changes in population structure

• To provide data for model validation by developing and applying new interdisciplinary techniques to a wide spectrum of biological and physical parameters

• To develop a database and information system for historic and new data and models.

The programme was composed of two phases: Phase 1 projects (2000-2002) focused on the use of historical datasets and existing biological models, complemented by laboratory experiments and remote-sensing analyses to gain a better understanding of the dynamics of zooplankton populations in shelf seas. The main, field-based Phase 2 of the programme (2001-2005) focused on the open ocean. The fieldwork phase took place between November 2001 and December 2002 and consisted of four surveys in the northern North Atlantic in early winter 2001 and 2002, and in spring and summer 2002.

MarProd was a major UK contribution to the international Global Ocean Ecosystem Dynamics project (GLOBEC).

Data Activity or Cruise Information

Cruise

Complete Cruise Metadata Report is available here

Fixed Station Information

No Fixed Station Information held for the Series

BODC Quality Control Flags

The following single character qualifying flags may be associated with one or more individual parameters with a data cycle:

SeaDataNet Quality Control Flags

The following single character qualifying flags may be associated with one or more individual parameters with a data cycle: