Metadata Report for BODC Series Reference Number 648047

• 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

No Problem Report Found in the Database

James Clark Ross 84 VMADCP Data Quality

Data Originator Comments

The data originators were pleased with the operation of the vessel mounted ADCP during the cruise, reporting reliable velocity information being obtained to depths of ~350m in water-tracking mode and ~550m in bottom-tracking mode.

BODC Quality control

Post transfer to BODC internal format (QXF) the data where manually screened using BODC XERPLO visualisation and quality control software. The data were viewed as a continuous time series.

On the whole, the data appear to be of good quality.

Visual inspection of the data confirms the reliable data in water-track mode to exist to depths of ~350m, with variation between 230m and 390m between files.

Notable spikes occur throughout the series, most often at around 10:00 or 22:00. It is surmised that these spikes are due to ship operations, but this has not been confirmed. Therefore, users are advised to use these data with caution.

Also of note is the period of 04:00 to 13:45 on 4 April 2003, where strong winds were reported in the cruise report, manifesting themselves as highly variable data within the VMADCP record. The VMADCP record is also absent from 11:15 on 30 March 2003 to 16:00 on 2 April 2003.

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.

James Clark Ross 84 150 kHz VMADCP processing

The following is adapted from the cruise report:

The system was operated in two modes: water-track mode, when water depths were greater than ~ 500m and bottom-track mode in shallower waters. In general, the ADCP worked very well with water-track velocity information generally obtained to ~ 350m depth and bottom-track velocity information to ~ 550m.

The configuration of the ADCP

The RRS James Clark Ross is fitted with an RD Instrument's 150 kHz (although actually 153.6 kHz), hull-mounted Acoustic Doppler Current Profiler (ADCP). Unlike other NERC research ships, the orientation of the transducer head on the JCR is offset by approximately 45° to the fore-aft direction in hope that the instrument will give a better response in the main direction of motion (i.e. fore-aft). To provide protection from ice, the transducer is mounted in a sea-chest recessed into the hull of the ship, which is again, different from the design of other British research ships.

The contents of the sea-chest are isolated from the surrounding sea water by a 33mm thick window of Low DensityPolyEthylene (LDPE). Within the sea-chest, the transducers are surrounded by a liquid composed of 90% de-ionised water and 10% ethylene glycol.

The version of the firmware used by the ADCP was 17.07 and the version of RDI Data Acquisition Software (DAS) was 2.48. The software ran on a Pentium 2 266Mhz running DOS.

For JR84, the ADCP was configured to record data in 64 x 8 bins and in ensembles of 2 minute duration. The 'blank beyond transmit' was 4m, which when added to the approximately 6m depth of the transducer, resulted in the depth of the centre of the first bin depth, being 14m.

In water depths of less than 500m, the ADCP was operated in bottom-track mode. Water-track mode was used in deeper water. The bottom-track mode was configured through the Direct Command menu of the DAS software using the command FH0004. This sets the instrument to one bottom-track ping for every four water-track pings.

The ADCP does not log to the SCS system, unlike all other underway scientific instruments on the RRS James Clark Ross, but instead, the 2 minute ensembles of data are fed directly into the ship's Level C system. In the event of a problem with the ship's Level C system, the data have to be recovered from the PC files, but no such problems were encountered during JR84.

Standard method of processing

The steps involved in processing the data are detailed below. The data were read into pstar files of 12 hour periods from the Level C system and processed using the pstar processing software. The programs involved, also require data from several navigation streams (described in the navigation data report).

Step 1 - Reading data

The data were read in and saved in 12 hour periods (00:00 to 11:59 and 12:00 to 23:59) using the Unix script 84adpexec0. This processing produces two output files: one containing the water-track data and one containing the bottom-track data. When the ADCP was set to record only water-track information, the bottom-track file contains only engineering data and zero's for the bottom velocity.

Output files: 84adp**** (**** = 3 digit Julian day plus a or p for am or pm), 84bot****

Step 2 - Water velocity / temperature correction

84adpexec0.1 performs a correction on the water- and bottom-track velocity data due to the presence of the de-ionised water / ethylene glycol mix within the sea-chest. This correction was derived by Mike Meredith (BAS) and Brian King (SOC). The following text is Dr Meredith's description of the steps involved:

The ADCP DAS software assumes that the fluid surrounding the transducers is ambient seawater and derives a speed of sound through measured temperature at the transducer head and an assumed salinity of 35. However, a correction is clearly needed to account for the fluid being the 90% de-ionised water / 10% ethylene glycol mixture instead of seawater.

From point measurements obtained from RDI, we previously derived the following equation for the speed of sound through the mixture as a function of temperature:

C = 1484 + 3.6095t - 0.0352t²

The individual velocity measurements from which this equation was derived to an accuracy of 0.01%, with the environmental conditions being known to within ±35kPa pressure and ±0.5°C temperature was used to derive a correction term to adjust the speed of sound assumed by the DAS to one appropriate for the mixture in the sea-chest. The correction term was:

(1484 + 3.6095t - 0.0352t²) / (1449.2 + 4.6t - 0.055t² 0.00029t²)

This correction is applied to both the raw water and bottom-tracked velocities using the Unix script 84adpexec0.1. A further correction for temperature is applied in this script, due to the temperature-dependency of the velocity scaling correction A (see later). This correction was the value derived on JR55, i.e. (1-0.00152*temp).

Input files: 84adp****, 84bot****

Output files: 84adp****.t, 84bot****.t

Step 3 - Time correction

The DAS software time stamps the ADCP data. This time stamp comes from the Pentium 2, which drifts at a rate approximately one second per hour. To correct this to the ship's master clock, the two clock times were read several times a day and the difference calculated. The Julian date (JDAY), ADCP clock reading and calculated time differences were entered into the time correction file, 84_start_adp_go(which also runs84adpexec0, 0.1 and1. From this calculated time drift, a correction was derived and applied to the ADCP data time using the Unix script84adpexec1.

Input files: 84adp****.t, 84bot****.t

Output files: 84adp****.corr, 84bot****.corr

NB: 84adpexec1 should be run 12 hours in arrears to allow for the corrected time falling outside of the 12 hour input file period, which will cause the program to fall over.

Step 4 - Correction for gyrocompass error

The ADCP measures water velocity relative to the ship. To calculate east and north water velocities from ADCP data, information is required on the ship's heading and velocity over the ground. This is partially fulfilled with input from the ship's gyrocompass (described in the ship's navigation report). However, it is well known that in addition to having an inherent error, gyrocompasses can oscillate for several minutes after a turn, before steadying on a new course. There is also an additional deviation of the gyrocompass that varies as cosec (latitude).

To overcome these difficulties, the ADCP is 'corrected' with data from the Ashtec ADU-2 (see navigation report). The Ashtec cannot be used instead of the gyrocompass because Ashtec coverage is not continuous, but the data can be corrected on an ensemble by ensemble basis. As a result of the 'standard processing' as detailed in the navigation report, the edited Ashtec data are held within a file as data of 2 minute averages. These data still contain large 'spikes', which are removed using an interactive editor. Any gaps created by this editing or previously existing in the data, are linearly interpolated by a further program. The gyrocompass correction file (84ash01.int) is then applied to the ADCP data through the Unix script 84adpexec2

The east velocity (velew) and north velocity (velns) from the ADCP are converted to speed and direction and the heading correction (as calculated from the gyrocompass correction file) applied to both the gridded water-track data and non-gridded bottom-track data. The program then converts the data back to east and north velocities ready for the A and phi calibrations performed in the next processing step.

Should there be no Ashtec correction to be made, this exec can be replaced by one that adds a dummy (zero value) correction variable (a-ghdg) or subsequent processing steps can be modified to omit this variable.

Input files: 84adp****.corr, 84bot****.corr, 84ash01.int

Output files: 84adp****.true, 84bot****.true

Step 5 - Calibration of the ADCP data

A final correction is now required to correct for the misalignment between direction as defined by the Ashtec ADU-2 antenna array and the actual direction of the ADCP transducers. This correction is called the heading misalignment, phi. There is also an inherent scaling factor, A associated with the ADCP, by which the water velocities must be multiplied to scale them correctly. The method of calculatingA and phi is described below. These calculated corrections were then applied to both water-track and bottom-track velocity data through the Unix script84adpexec3.

The calibration values used during JR84 were: A = 1.0284 and phi = -1.68.

Input files:84adp****.true, 84bot****.true

Output files: 84adp****.cal, 84bot****.cal

Step 6

The data now contain calibrated water velocity relative to the ship. To derive absolute velocity, the files are merged with position form the 'bestnav' navigation file (see navigation report) and derive ship velocity between ensembles. This velocity is then removed from the water velocity data to give absolute water velocity. This is performed using the Unix script 84adpexec4.

Input files: 84adp****.cal, 84bot****.cal

Output files: style='font-family:TimesNewRoman'>84adp****.abs, 84bot****.abs

Method of derivation of the calibration coefficients A and phi

1. Periods when the ADCP gave bottom-track velocities (i.e. when the ship was working in water depths generally less than 500m) were identified.

2. The files with bottom-track velocities were then calibrated with a nominal scaling in 84adpexec3 by setting the scaling factor, A, to one and the misalignment angle, phi, to zero.

3. The two minute ensembles of ADCP data were then merged with 'bestnav' position fixes. From these 'bestnav' fixes, the ship's east and north velocities overground were calculated. Time periods within each data file were then identified where the ship's heading and velocity did not deviate greatly over a period of at least 6 minutes.

4. The ADCP bottom-track velocities were then multiplied by -1 as the velocity of the ship given by the 'bestnav' fixes is in the opposite sense to the velocity of the bottom as derived by the ADCP.

5. Values for A and phi for each time period were then derived using vector mathematics and the following formulae:A = U_GPS/ U_ADCP Where U_ADCPis the bottom-track ADCP derived ship speed and U_GPS is the GPS position fix derived ship speed (that is, ship speed over ground) phi = phi_GPS - phi_ADCP Where phi_GPS is the direction of motion of derived from the GPS navigational fixes and phi_ADCP is the direction of motion as derived from the bottom-track ship's motion. This was achieved using the Unix scriptadcp_calibration_exec.

Input files:84bot****.abs

Output files: 84bot****.abs.#2 (where # = a or p for am or pm)

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 transferred 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.

James Clark Ross 84 Navigation

The following is adapted from the cruise report:

There were five navigational instruments for scientific use on the RRS James Clark Ross (listed below). Although the five instruments appear in some cases to be similar, they are all unique. As well as the three GPS systems listed, there are additional GPS systems on board the JCR for the ship's use. These are a Leica MX400 and two Ashtec G12 receivers as part of the dynamic positioning system. In addition, there is a Racal Satcom, which receives GPS SV range correction data via INMARSAT B. These data are passed to the Trimble, Leica and G12 receivers allowing them to operate in Differential mode (DGPS). During JR84 the DGPS reference station at Stanley was used.

The collection and use of all of the navigation data are linked. All of the instruments are currently logged to the SCS system and then transferred to the old RVS Level C system where they are currently read.

During cruise JR84, the data for all five instruments and the standard editing procedures were done in one Unix script called jr84_nav_go. This script requires the Julian day and am or pm selection as input and then executes a further 8 C shell scripts to read in 12 hours of data and edit where necessary, all five streams. This report briefly describes each instrument and explains the processing as was performed on cruise JR84.

The Instruments

Trimble 4000

The Trimble 4000 receiver in differential mode, was the primary source of positional information for the scientific work on JR84.

The data were logged at 1 second intervals and read into pstar files in 12 hour periods from the SCS derived Level C stream using the Unix script gpsexec0. Individual steps in this exec are as follows.

Output files: 84gps****.raw (just before editing stage), 84gps**** (following datpik )

Ashtec GLONASS (GG24)

The Ashtec GG24 accepts data from both American GPS and Russian GLONASS satellite clusters, giving a constellation of 48 available satellites and should, theoretically, be more accurate. However, experiments on previous cruises have suggested that the accuracy is significantly lower than the differential GPS.

Data were logged routinely using ggexec0, called from jr84_nav_go, but were not used in the processing of other data streams.

Output files: 84glo****.raw, 84glo**** (following basic quality control of raw data)

Ashtec ADU-2

The Ashtec ADU-2 GPS is used to correct errors in the gyrocompass heading that are input to the ADCP. The configuration of the receiver is complex, made more so by the fact that the receiver can only be configured with the use of a laptop running a terminal emulation program.

Configuration data for the Ashtec aerial configuration is shown below. The port-aft antenna is designated number 1, port-fwd is number 2, stbd-fwd is number 3 and stbd-aft is number 4. the XYZ vectors have been adjusted so that heading is defined by the direction normal to the 1-4 baseline (i.e. that baseline has Y = 0).

The Ashtec functioned well during JR84 apart from a number of periods when no data were received (see table below for times and durations). This was very unfortunate because of the implications for ADCP processing. It also could have been easily avoided if we had maintained regular watches.

Our complex data processing is designed with using the Ashtec to correct the gyrocompass error in mind. There are were three execs involved in the processing: ashexec0 ashexec1and ashexec2.

Output files: 84ash****.raw

Output files: 84ash****.mrg

Output files: 84ash****.edit, 84ash****.av

A manual editing procedure was then performed, as described in the ADCP data processing report.

Gyrocompass

The gyrocompass is a fundamental data stream. It is used by the RVS program bestnav to derive dead reckoning in the absence of GPS data, as well as being used for ADCP processing (ADCP report) and derivation of true wind velocity (ocean logger report). For JR84, the gyrocompass data were read in 12 hour time periods using the Unix exec gyroexec

Output files: 84gyr****.raw

The script also appends the day file to the master file called 84gyr01.

Electromagnetic Log

The Electromagnetic Log gives water velocity relative to the ship in both the fore-aft and port-starboard direction. These data were read in 12 hour time periods using a simple exec emlexec0.

Output files: 84eml****.raw

Doppler Log

The Doppler Log gives water velocity relative to the ship in both the fore-aft and port-starboard direction. These data were read in 12 hour time periods using dopexec0.

Daily navigation processing

As stated above, the data were read in as twice daily (12 hour) files; the time periods being either from 00:00Z to 11:59Z or 12:00Z to 23:59Z. Our primary navigation data were taken from the RVS file bestnav. This program uses the navigation data from various streams to construct a file with 30 second fixes. For JR84 the primary input to bestnav was the Trimble 4000 DGPS. This navigation file was read into a pstar file using the script navexec0.

Ouput files: abnv841

The output master file, abnv841, is used for all pstar required navigation information (e.g. ADCP processing).

The processed data were then averaged and filtered using navexec1.

Output files: abnv841.av

Project Information

AutoSub Under Ice (AUI) Programme

AutoSub was an interdisciplinary Natural Environment Research Council (NERC) thematic programme conceived to investigate the marine environment of floating ice shelves with a view to advancing the understanding of their role in the climate system.

The AUI programme had the following aims:

• To attain the programme's scientific objectives through an integrated programme based on interdisciplinary collaborations and an international perspective
• To develop a data management system for the archiving and collation of data collected by the programme, and to facilitate the eventual exploitation of this record by the community
• To provide high-quality training to develop national expertise in the use of autonomous vehicles in the collection of data from remote environments and the integration of such tools in wider programmes of research
• To stimulate and facilitate the parameterising of sub-ice shelf processes in climate models, and to further demonstrate the value of autonomous vehicles as platforms for data collection among the wider oceanographic and polar community

Following the invitation of outline bids and peer review of fully developed proposals, eight research threads were funded as part of AUI:

Physical Oceanography

• ISOTOPE: Ice Shelf Oceanography: Transports, Oxygen-18 and Physical Exchanges.
• Evolution and impact of Circumpolar Deep Water on the Antarctic continental shelf.
• Oceanographic conditions and processes beneath Ronne Ice Shelf (OPRIS).

Glaciology and Sea Ice

• Autosub investigation of ice sheet boundary conditions beneath Pine Island Glacier.
• Observations and modelling of coastal polynya and sea ice processes in the Arctic and Antarctic.
• Sea ice thickness distribution in the Bellingshausen Sea.

Geology and Geophysics

• Marine geological processes and sediments beneath floating ice shelves in Greenland and Antarctica: investigations using the Autosub AUV.

Biology

• Controls on marine benthic biodiversity and standing stock in ice-covered environments.

The National Oceanography Centre Southampton (NOCS) hosted the AUI programme with ten further institutions collaborating in the project. The project ran from April 2000 until the end of March 2005, with some extensions to projects beyond this date because of research cruise delays. The following cruises were the fieldwork component of the AUI project:

Table 1: Details of the RRS James Clark Ross AUI cruises.

All the cruises utilised the AutoSub autonomous, unmanned and untethered underwater vehicle to collect observations beneath sea-ice and floating ice shelves. AutoSub can be fitted with a range of oceanographic sensors such as:

• Conductivity Temperature Depth (CTD) instruments
• Acoustic Doppler Current Profillers (ADCP)
• A water sampler
• Swath bathymetry systems
• Cameras

In addition to use of AutoSub during each cruise measurements were taken from ship. These varied by cruise but included:

• Ship underway measurements and sampling for parameters such as:
  • Salinity
  • Temperature
  • Fluorescence
  • Oxygen 18 isotope enrichment in water
  • Bathymetry using a swath bathymetry system
• Full-depth CTD casts for with observations of samples taken for parameters such as:
  • Salinity
  • Temperature
  • Fluorescence
  • Optical transmissivity
  • Dissolved oxygen
  • Oxygen 18 isotope enrichment in water
  • Water CFC content
• Sea floor photography and video using the WASP system
• Sea floor sampling with trawls/rock dredges
• Sea ice observations (ASPeCt), drifters and sampling

The AutoSub project also included numerical modelling work undertaken at University College London, UK.

The project included several firsts including the first along-track observations beneath an ice shelf using an autonomous underwater vehicle. The AutoSub vehicle was developed and enhanced throughout this programme and has now become part of the NERC equipment pool for general use by the scientific community. Further information for each cruise can be found in the respective cruise reports (links in Table 1).

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: