Given these objectives, the desired outcomes of the workshop were considered to be:

The WOCE UOT Data Assembly Centre (DAC) is quite a complex arrangement and there are several components constituting the DAC. The WOCE system has evolved around the GTSPP (Global Temperature and Salinity Pilot Project) which was set up to improve the world wide exchange and archiving of ocean temperature and salinity data. Any particular temperature profile may go through a number of different routes and QC procedures on its way to the final archive at the World Data Centre A (WDC-A). This Workshop is committed to considering only the WOCE UOT data system so this document does not deal directly with other aspects of the GTSPP or other QC systems. The majority of the data are from Expendable Bathythermographs (XBTs) but many other profiles are generated from CTDs, moored buoys, drifting buoys with thermistor chains etc.

Briefly, the real time (RT) data are received daily at the Marine Environmental Data Service (MEDS), Canada, and sent to US National Oceanographic Data Centre (NODC) 3 times per week. These data have come from ships via some operational centre and onto the GTS (Global Telecommunication System) which relays them to MEDS and other centres around the world. The delayed mode (DM) high resolution data are sent from ships to each programme centre, and then to NODC, sometimes via a national data centre. All real time data are inserted onto the GTS within 30 days of collection; delayed mode data should be sent to NODC within 1 year of collection, but often the delay is much longer. Simple tests for data integrity are carried out on RT data at MEDS and DM data at NODC, based on the IOC Manuals and Guides No. 22. Periodically, yearly sets of combined real time and delayed mode data (with duplicates removed) are transferred to the "regional" Science Centres (one for each ocean) where they undergo scientific quality control. Note delayed mode data replace the real time version of a profile in the NODC database. Finally the QC'ed data sets are returned to NODC and hence to the archives at the Global Subsurface Data Centre in Brest, France and the World Data Centres (WDC-A). See Section 8 for further details of time scales for final data sets.

Figure 1 summarizes the routes WOCE upper ocean thermal data take as they go through the QC system. Centres where QC is performed are marked as such. Time frames are indicated, but those which are targets not yet being met are indicated with an asterisk(*).

Figure 1. WOCE Upper Ocean Thermal Data Assembly.

The Science Centres are:

The terminology of the WOCE UOT DAC system has grown, to a certain extent, from historical phrases and terms. This leads to some confusion unless it is made clear what each term refers to. Throughout this document the following terms will be used:

The submission of delayed mode data is well known to be very slow; figures provided by NODC and the Global Centre indicate that only approximately 15% of the 1992 real time data have been replaced by the delayed mode profiles at this time (2-3 years after collection). The IOC/IODE guideline and WOCE requirement is for originators to submit their data 1 year after collection. The IPO and NODC are currently investigating which data originators have not submitted their delayed mode data for collection year 1992 and will at the same time, remind originators of the WOCE and IODE requirements for all UOT data.

As Figure 1 shows, the data originators are the first point for quality control of the delayed mode data. Some organizations carry out extensive QC and others do very little. In general, research organizations are more likely to inspect, flag and clean up data than operational groups. This QC of data before submission is considered by the UOT DAC group to be desirable since the individuals who collect the data are in a good position to judge the quality of their own data. Thus it is important for data centres to retain QC information and flags provided by originators. It is also essential that the data centres retain the documentation relating to those flags, so that users know exactly what they mean. The Workshop recommended that as a general principle national oceanographic data centres should retain quality information and flags provided by data originators, along with the associated documentation. NODC currently stores all originators datasets in their original formats, and will soon be digitizing or scanning all original documentation, which will be available to requesters. This is not happening at every centre at present, and not all originators are performing extensive QC themselves before submission.

It was noted that data which in the past have been flagged as "bad" may in fact be recognized later as good data. For example, "inversions" may be flagged as bad data but with accumulated local knowledge the QC operator may recognize that such features can be real in that particular area. The CSIRO group has experienced this situation with data collected though their VOS programme and now submit all data to NODC. This is an example of the added value the Science Centres bring to the WOCE data set, and also provides a warning not to discard apparently bad data. The Science Centres have the necessary expertise to make the judgment between flags 2, 3 and 4, and rather than risk some probably good data being lost, the Workshop recommended that originators be asked to submit all data, including those they consider to be bad, with the appropriate flags attached. Otherwise the science centres will only be able to remove erroneous data, and not reinstate good data which was previously flagged as bad (such as climate signals which may have been removed due to the data looking different to other data in the area).

Some of the data in the WOCE data sets QC'ed by the Science Centres are in the form of BATHYs which have not been replaced by delayed mode data. Because of the low resolution of BATHYs, it is often difficult to make a scientific judgment as to whether a feature is real or not. Some systems for generating BATHY messages apparently create a higher number of inflexion points than others. It was noted that in general, profiles with a high number of inflexion points are more suitable for QC. The Workshop recommended that originators be informed of this general point and be encouraged to set their systems to generate BATHYs with a high number of inflexion points.

The demonstrations of Science Centre QC systems prompted detailed discussions on how decisions about data quality were taken. Table 2 shows the percentages of different data flags derived by the three centres after QC of the 1990 data set. Variations in the percentages occur in flags 1 and 2 due to the different definitions and approaches adopted by each centre. Basically though, the difference is generally non-consequential to the user as the data are still "good". Figures for flags 3 and 4 are similar.

In the past, the UOT DAC coordination group decided that data below a flagged feature should be flagged at the "worst" level given to the feature (here flag 4 being "worse" than 1 etc.). In other words, all data below data flag 3 should also be given flag 3. This decision arose after concern that the instrument could not recover after a spike or a wire stretch. In many cases this is true, however a spike caused by outside effects such as radio transmission interference does not affect the quality of the data below. The Science Centres therefore agreed that in individual cases the scientific operator should make the subjective decision as to whether the profile recovered below the feature flagged 3 or 4.

The Chairman drew the attention of the Workshop to the fact that the top few metres of temperature data from an XBT profile are bad or probably bad because of the time it takes for the thermistor to equilibrate. The IGOSS Task Team for Quality Control of Automated Systems (TT/QCAS) have studied the phenomena and concluded that on average the top 0-3.7 m of XBT data are unreliable. The Workshop recommended that the Science Centres replace the top 3.7 m of high resolution delayed mode data with absent data values and assign the data a flag 5 (Changed Value) and code Erroneous Surface Feature. Original data must be retained in the history table. It was agreed that this should only be applied to high resolution data, because low resolution inflexion point data (such as BATHY messages) do not provide enough resolution to indicate at which depth the data become good. See also Section 4.2 for discussion on deleting and editing data.

The CSIRO Cookbook provides an extensive list of accept and reject QC codes, while the AOML and SIO groups use a more limited set of codes which are mainly reject. The Workshop agreed on a core list of standard codes to be used by all three Science Centres. As codes naturally evolve in time, it is recommended that information on the code version and dates applied be stored with the data.

CSIRO believes that flagging "real" feature information, such information is included and used in the ongoing QC process, results in growing expertise for their region. However, the Workshop repeated the recommendation that Accept codes are not compulsory at all Science Centres.

The Workshop was unsure whether Southern Ocean data were included in the datasets from NODC, and whether each Science Centres were examining data from the Southern Ocean part of their basins.

[Note: NODC confirmed they are building a global data set, July 1995]

At present, data which lie outside 3 standard deviations from the Levitus climatology mean are automatically given Flag 2 (to indicate "inconsistent" data) at some Centres. It was agreed that this was not desirable since some good profiles will lie outside of the climatology, especially in areas where the climatology is based on a small amount of data. In general climatology should be used as a guide to the standard of a profile and should data lie outside of it, then this should be brought to the attention of the QC operator who can then make a judgment as to what the appropriate flag should be.

The Science Centres utilize "waterfall" displays with neighbouring profiles plotted each slightly offset from the next. These have proved very useful for generally comparing each profile with neighbouring ones, and can reveal whether a feature is consistent across 2 or more profiles. However, waterfall plots do not allow the QC operator to detect many faults associated with XBTs, for example, where malfunctions are often characterized by drifts to warmer temperatures after particular faults. Such differences are almost impossible to detect by eye when the profiles are arbitrarily offset in the waterfall plots. The best way to detect such errors is to overlay the profile under consideration with it's neighbouring profiles, so that any unusual temperature differences at depth can be evaluated.

1. Erroneous Temperature/Depth Offset (reject - 3/4)

The temperature profile exhibits erroneous temperature/depth offsets compared to neighbouring profiles and/or climatology and/or known characteristics of the region. The offsets can occur at depth, or over sections of the profile, or over the complete profile. (The reason could be instrument drift/sensor failure, encoding error, XBT fall rate error, XBT start-of-descent timing error, etc.)

2. Erroneous Constant Temperature (reject - 3/4)

The temperature profile exhibits constant temperature which is considered to be erroneous when compared to neighbouring profiles and/or climatology and/or known characteristics of the region. The constant temperatures could occur over all of the profile or part of it. (The reasons could be sensor failure, depth calculation error, nose falling off the XBT, XBT sitting on the bottom, etc.)

3. Erroneous Surface Feature (reject - 3/4)

The temperature exhibits erroneous features at the surface when compared to neighbouring profiles and known characteristics of the region. (The reasons could be XBT start-up transients, general instrument equilibration problems, sensors recording prematurely before entering water, etc.)

4. Erroneous Mixed Layer Feature (reject - 3/4)

The temperature profile exhibits erroneous features (such as false inversions) in the mixed layer when compared to neighbouring profiles and/or climatology and/or known characteristics of the region. (The reasons could be the XBT bowing problem, instrument drift, etc.)

5. Erroneous Temperature Inversion (reject - 3/4)

The temperature profile exhibits erroneous temperature inversions when compared to neighbouring profiles and/or climatology and/or known characteristics of the region. (The reasons could be XBT wire stretch, sensor drift, encoding error, etc.).

6. Erroneous Fine Structure (reject - 3/4)

The temperature profile exhibits erroneous fine structure when compared to neighbouring profiles and/or climatology and/or known characteristics of the region. (The reasons could be signal leakage, XBT recording system failures (sticking bit, cusping, PET Fault, etc.), complete instrument failure, etc.)

7. Erroneous Temperature Gradient (reject - 3/4)

The temperature profile exhibits erroneous temperature gradients when compared to neighbouring profiles and/or climatology and/or known characteristics of the region. (The reasons could be spiking, interference, XBT wire break, modulo 10 problem, XBT wire insulation penetration, etc.)

1. Under-resolved Profile (accept - 1/2)

Temperature data is encoded at standard depths/levels and cannot be used to reconstitute a profile accurately (depth resolution > 10m??).

2. Duplicate Profile (reject - 3/4)

Exact or near-exact temperature profile already exists in an higher resolution form.

3. Position Error (accept/reject - 2/3/4)

Profile position has been erroneously encoded. Corrected if possible.

4. Date/time Error (accept/reject - 2/3/4)

Profile date/time has been erroneously encoded. Corrected if possible.

A useful addition to waterfall plots is some measure of profile-to-profile temperature difference at depth. It was recommended that "waterfall" plots and overlaying buddies be added to all Centres' QC procedures to provide extra information to the QC operator.

The Workshop continued the debate about whether or not to alter data. Each profile undergoes position and date/time tests at MEDS (real time) and NODC (delayed mode) and when errors are found, the Workshop recommended that data should be changed if the operator has a high degree of confidence in the corrected value. The original values must be retained in the history table and the new values given Flag 5. As a small number of position and date/time errors may slip through the MEDS and NODC QC procedures, this recommendation also applies to the Science Centres which test for these errors.

More controversial is the issue of whether or not to delete spikes within the profile. Many participants felt it is not appropriate for QC centres to delete spikes and interpolate across the gaps. However, it was recognized that the data originators who have close knowledge of their data do have the ability to remove spikes where appropriate, and many do this to "clean up" the data sets. (This relates to the recommendation made in Section 3.1 that the data centres should retain quality information provided by data originators). CSIRO considered that the Science Centres are in a qualified position to clean up bad data where possible (such as spikes) for the users, as long as the original values are stored in the history record. The role of the WOCE QC system is to provide users with the best quality dataset possible. It was eventually agreed that all QC Centres must not delete spikes from the WOCE data set, but instead the spikes must be flagged.

The issue of the overall profile flag was raised; GTSPP assign in the header information, a single flag which is intended to simply convey the overall quality of the profile. At present this flag is assigned based on the "worst" flag present in the profile, i.e. if at least one point is flagged 4 then the overall profile flag is also 4. The intention is to enable the data centres to retrieve all profiles which have no bad data in them. A search on this basis would then exclude all profiles with spikes or bottom "tails". It was suggested however, that users would want to retrieve all good data, including the data in profiles which had some bad points; the bad data from those profiles being discarded for analysis purposes.

The use of the overall flag is limited whichever meaning it has, and Data Centres do not in practice select profiles for a user on the basis of this flag alone. However, the Workshop recommended that the GTSPP consider a new approach to the overall profile flag; that it could be assigned according to the "best" flag present.

All QC centres should maintain constant feedback on the quality of data to the data originators. Data originators should in particular be made aware of problems with particular platforms, etc. It is important to not only flag bad data at the QC centres, but to also help address and fix problems with the data collection. MEDS have been very efficient in undertaking this activity with the real-time data and are to be commended. CSIRO are in the fortunate and effective position of being data originators and a science centre.

It was noted that not all the data in the UOT data sets are actually profile data. Some data are recorded at selected/standard depths. Care must be undertaken to alert users that these data do not constitute profile information, and this data must be QC'ed accordingly.

Attention was drawn to the study of the IGOSS TT/QCAS (refs 2,3,4) on the fall rate (and hence depth) errors of the XBT. It was pointed out that only some of the more commonly used types of XBTs have been evaluated so far. It is essential that all UOT XBT data subsets wherever possible retain information on the type of probe, recorder, and depth equation used to record the profile. Without such information, the data cannot be corrected for depth errors if present. NODC is retaining such information if indicated from the originator.

The issue of whether or not depth corrections should be applied to existing data was discussed. The TOGA/WOCE XBT Programme Planning Committee and the GTSPP steering committees have recommended that these should not be applied since existing data sets do not contain the necessary information to determine what instruments were used to obtain the profile and what corrections have already been made.

The Workshop agreed it was essential to provide the scientific community and users of these datasets with information on how the system works, what the QC procedures are and where data are available. All centres have, or will shortly have World Wide Web (WWW) sites in which to display information about their activities. The Workshop recommended each centre implement a Web page giving an outline of their procedures, while the Data Information Unit (DIU) which is the central facility for WOCE data information, will provide the system overview and the global definitions of Flag and Codes.

It was noted by Tim Boyer that the flags attached to the GTSPP data centre available from NODC may be ignored by some users because it was not immediately obvious to the users what they mean or where to find the documentation. The Workshop felt it was essential to point the user of GTSPP and WOCE data sets to the appropriate documentation when they retrieve data.

The UOT data set should also contain data from instruments other than XBTs, including CTDs, MBTs, drifting buoy thermistor chains, moored buoys etc. The Workshop agreed it was essential that these data also be included in the data sets sent to the Science Centres from NODC. The Indian Ocean UOT DAC has only received XBT data. Relating to this, MEDS as the Drifter RNODC and WOCE Drifter DAC, was requested to include profiles from drifting buoys with thermistor chains in the WOCE UOT data set sent to NODC. Single point data (location and sea surface data) from drifting buoys are NOT required in the UOT data sets. However, profiles should not be deleted from the UOT data set if after editing only the surface values remain.

The Workshop discussed the ways in which the various components of the UOT QC system can achieve and maintain the global consistency which is the culmination of the past years of developing the system. This Workshop represented almost the final stage in achieving standardization though 3 separate scientific systems. The strict definitions of flags and codes were agreed on, and a simple comparison of procedures and statistics of numbers of flags indicated the 3 Science Centres followed similar processes. Some adjustments still need to be made as a result of this Workshop; a fine tuning of the system in effect. In order to maintain this level of consistency the Workshop agreed a document containing the globally consistent rules, policies and procedures of the system was needed. The "UOT DAC QC Handbook" as it would be known, would be of use to the QC Centres, the data users, and to other data centres and programmes.

The agreement at the Workshop on flag and code definitions will mean that Science Centres will have to re-visit some of the 1990 data they have already quality controlled. This is desirable to achieve a truly globally consistent data set from 1990 onwards. In actual fact not every profile will need to be individually re-inspected; only the flagged profiles may need some revision. The removing of the surface 3.7 m of data can be performed in batch mode.

In order to quantify the global consistency of the system, and to provide information on the added-value of regional knowledge, it was agreed that all QC Centres should QC some subset of RT and DM data, including data from all 3 oceans (MEDS should QC just the RT and NODC just the DM). This study should occur after the standardization agreed on at this meeting has been implemented, but it must be completed and ready for discussion at the next UOT DAC meeting (February 1996).

The Workshop discussed the schedule for the 1991 and later delayed mode datasets. The WOCE requirement for delivery of the scientifically QC'ed data sets to the Global Centre is 1.5 years after the end of the observation year, so the 1991 onwards data are seriously behind schedule. This is a result of slow submission of delayed mode data and a result of the length of time it has taken to develop the QC system. At present, the amount of delayed mode data at NODC for observation year 1992 is something like 15%. Clearly it does not make sense to proceed with scientific QC with such a small amount of high resolution data. The WOCE IPO and NODC are working to reduce the time lag for delayed mode data to be submitted (Section 3.1), and the Science Centres have agreed to reduce the time between the processing of yearly batches. The following table indicates the original WOCE timetable for each yearly dataset (Due), and the actual completion dates or those agreed at the Workshop (Scheduled).

The final archive of the WOCE UOT data is the WDC-A and the Global Subsurface Data Centre in Brest. During the demonstration of the Brest QC and archiving system, the Workshop was reminded that the original files received from NODC are stored at the resolution at which they are received, but that the working archive (from which data are retrieved for users) consists of data with reduced resolution. The UOT DAC group has been informed of this reduction of data previously, and at the meeting in Hobart in April 1993 (UOT/DAC4, WOCE Report No. 106/93) the group requested that the Global Centre investigate ways to archive and retrieve data at the resolution received from NODC. This Workshop reiterated that request to the Global Centre.

The Workshop touched on the issue of what the WOCE UOT data system wishes to achieve in the long-term (i.e. post-WOCE) and what the benefits to other programmes could be. In general, as much as possible of the expertise currently being accumulated at the Science Centres needs to be passed on to national data centres, so that when the Science Centres no longer exist their skills can be utilized elsewhere. The Workshop views this as an ongoing process and suggestions such as those made in Section 4.2 are steps towards that goal. While a long-term goal may be the development of a QC system with Artificial Intelligence, the Workshop recognized that such a system is still a long way off. Meanwhile interaction between the Science Centres and national and international data centres is essential. The Workshop recommended that the IOC/IODE should be informed of the intention to transfer the expertise of the Science Centres to national and international data centres. Such a transfer is already happening with the Indian Ocean UOT/DAC where CSIRO is training staff at the AODC on scientific QC, and the AODC are adopting CSIRO procedures and software in their own operations.

It was considered that presentations on the performance characteristics of XBTs and XCTDs would be helpful for the QC operators to understand the limitations of the equipment, and what the characteristic modes of failure appear like. This can help in the QC decision making process when QC operators are required to differentiate between real and subtle instrument malfunctions.

Representatives from Sippican Inc. gave very helpful technical demonstrations of new MK12 software, and the way the XBT functions with the possible sources of errors. The participants at the Workshop were also able to provide feedback to the Sippican Inc. representatives about difficulties and experiences they have with using XBTs. One example is the high failure rates of XBTs in high latitude areas with very cold water. If the XBTs are considerably warmer than the water when they are deployed they have a high failure rate; but simply storing the XBTs at a temperature close to the sea surface temperature reduces the probe failure rate. XBTs and XCTDs should not, however, be dunked in water before deployment. This leads to other problems with the probes. It was noted that a summary of this sort of information presented in a short, convenient way would be extremely helpful to the people deploying XBTs. The Workshop recommended that Sippican provide a short resumé of useful information about storing and deploying XBTs which could be placed with the equipment on board ships. IGOSS could also be utilized to spread the information as widely as possible.

Rick Bailey, as chairman of the IGOSS Task Team for Quality Control and Automated Systems (TT/QCAS), gave a presentation on the findings of the Task Team. Discussions related to identified problems with XBTs such as fall rate errors, the "bowing" problem, start-up transients, and start-of-descent timing delays.

It was agreed that the next meeting should be held in February 1996, and the Workshop recommended that it be held adjacent to the next GTSPP committee meeting. The suggested venue was NODC.

Bailey, R., A. Gronell, H. Phillips, G. Meyers and E. Tanner, 1994: CSIRO Cookbook for Quality Control of Expendable Bathythermograph (XBT) Data. CSIRO Marine Laboratories Report, 221, 75pp.

Hanawa, K., P. Rual, R. Bailey, A. Sy, and M. Szabados, 1995: A New Depth-Time Equation for Sippican or TSK T-7, T-6 and T-4 Expendable Bathythermographs (XBT). Journal of Deep Sea Research (in press).

Rual, P., K. Hanawa, R. Bailey, A. Sy, and M. Szabados, 1994: New Depth Equation for Commonly used Expendable Bathythermographs: Sippican and TSK T-4, T-6 and T-7 Probes. WOCE Newsletter, 17, 32pp.

UNESCO, 1994: Calculation of New Depth Equations for Expendable Bathythermograph's Using a Temperature-Error-Free Method (Application to Sippican/TSK T-7, T-6, and T-4 XBTs). IOC Technical Series, 42, 46pp.

1. Technical Presentations on Recording Instruments
- Sippican, Chairman of IGOSS Task Team for Quality Assurance of Automated Systems

2. Science Centres and Data Centres QC Procedures
- CSIRO, AOML, SIO, NODC, MEDS, Brest, NMC, GODAR. Demonstrations, description and discussion of QC procedures

3. Comparison of QC Procedures
- Comparison of QC statistics from 1990 data set

4. QC of Different Resolution Data Sets
- The implications for quality control, of data of varying resolution

5. QC of Different Data Sources
- The implications for quality control, of data from various instrument types

6. Standard Flags and Procedures

7. QC Procedures under development

8. Other and Remaining Items