FLOATER FORMAT The following is a description of the ASCII format used to store data from the subsurface floats. The records are variable length and are stored in an alphanumeric format. This format is designed primarily for ease of edit- ing, manual inspection of data, and transportability to other users and installations. Field Position Description --------- --------- ---------------------------------------------- EXPID 001-003 Experiment identifier; character. source This field is used to indicate the source or type of data. Usually the first two (2) characters (001 -002) contain the code, such as "CG" for Coast Guard. BUOYID 004-009 Buoy identifier; character. This field contains a six (6) character identifier to be associated with the buoy. The identifier must be left justified in the field and may not contain any embedded blanks. Trailing blanks are acceptable. DATE 010-015 Date; integer. iyear 010-011 The "DATE" field contains the date of the data imonth 012-013 observation. The date is stored as a year/month/day iday 014-015 combination. Only the last two digits of the year are used. Thus October 4, 1981 is stored as 811004. The zero is significant as a place holder. TIME 016-019 Time; integer. ihour 016-017 The "TIME" field contains the time of the data iminute 018-019 observation (GMT). The time is stored as a hour/minute combination. The hour component is taken from 00 to 24 hours. Thus, 3:08 p.m. is stored as 1508. The zero is significant as a place holder. LATITUDE 020-026 Latitude, degrees positive for North; real. This field contains the latitude position of the float at the time of the data observation. LONGITUDE 027-034 Longitude, degrees positive for East; real. This field contains the longitude position of the float at the time of the data observation. VALIDITY 035-040 Validity codes; character. This field is to be used for various validity codes. Some possible combinations are descibed below. PROCESS 035 Processing method. 1 - interpolated 3 - splined 4 - manual 5 - averaged 6 - Butterworth filtered POSITION 036 Position validity. This field is used to specify a code for those records which have a quality va- lue associated with the position acquisition. This field contains a relative qualitative value for the reliablity of the measurement. The valid range of values is currently 1 (poor) to 5 (excellent). A blank field or a zero is the default and repres- ents "unassigned." QUALITY 038 When used, a 1 or blank indicates acceptable qual- ity; a 2 in column 38 means WFDAC believes that the location is doubtful; a 3 in column 38 means that the float was aground at this point. VELOCITY 040 Velocity algorithm. 1 - backward differencing 2 - forward differencing 3 - splined 4 - Chebyshev 5 - averaged XEAST 041-050 East component of water velocity, cm/sec; real. The velocity may be computed in any of a vari- ety of methods; the method used (when known) is described in the appropriate validity field. A westerly direction of the velocity is negative. YNORTH 051-060 North component of water velocity, cm/sec; real. This field contains the local north component of the water velocity. Velocities to the South are negative. FIELD01 061-070 Parameter; real. field02 071-080 The remainder of the record contains various fields : of data associated with the instrument and position. (Note that this causes the records to be variable length, although all records should be the same length for a given experiment and buoy. Missing data is indicated by a null value - see below). Each field is ten (10) characters long. The first character of the field will always contain an indicator of the data field type. Once the field type has been determined the remainder of the field may be processed accordingly. Nominally the data will be stored in a G9.3 format. The codes are specified in the file below. 24 PARAMETER UNITS FORM MISSING - ------------ ------------ ---- -------- A WIND_SPEED M/SEC F9.3 -999.0 B WIND_HEAD. DEGREES F9.1 -999.0 C VALIDITY F6.0 blank D VERT_DISP METERS F9.1 -9999.0 E EAST CM/SEC G9.1 -9999.0 F WIND_SP_(H) M/SEC F9.1 -999.0 G WIND_VA_(H) (M/SEC)**2 F9.1 -999.0 H HEADING DEGREES G9.1 -999.0 I reserved G8.0 J JULIAN_DAY DAYS G9.0 -999.0 K UNSMOOTHED_T CENTIGRADE G9.2 -999.0 L WIND_SP_(8) M/SEC F9.1 -999.0 M WIND_VA_(8) (M/SEC)**2 F9.1 -999.0 N NORTH CM/SEC G9.1 -9999.0 O reserved F9.1 P PRESSURE(MAX)DECIBARS G9.2 -999.0 Q MIN PRESSURE DECIBARS G9.2 -999.0 S SALINITY PPM. G9.3 -999.0 T TEMPERATURE CENTIGRADE G9.2 -999.0 V SPEED CM/SEC G9.1 -9999.0 W VERT_VEL METERS/DAY F9.4 -999.0 X LONGITUDE DEGREES F8.3 -999.0 Y LATITUDE DEGREES F7.3 -99.0 Z DEPTH METERS F9.3 -999.0 An essay on the quality flags: * This is an attempt to define the quality flags now associated with * the FLOATER data as it is stored in the NetCDF format. Of course the * original status flags are carried along but what is desired is some * more quantitative method of ascribing a quality. It would also be * useful to retain the computation method and some of the other * information. Why not just leave the old flags as that seemed to do * everything? There was, as mentioned, the ambiguity. More importantly, * as the method of instrumentation and data collection has changed * through the years, the manner in which the processing is performed has * also changed. It is now possible for parameters to be measured * independently and also separate from the time/position determination. * We are therefore assigning a quality flag to time, position, velocity * and each parameter. The quality of the data will be assigned a value * ranging from 1 (low or bad quality) to 9 (good, high quality). This * is a relative, arbitrary scale and requires mapping from the many other * (fix) quality or other scales that have been or probably will come into * effect. The old FLOATER format did not generally have this quality * concept as the data was often irregularly spaced, then subsequently * smoothed and re-sampled. More recently collected data is quite reg- * ularly spaced, except for problems and, in the case of satellite- * acquired fixes, has an attached quality indicator. The following * table indicates the proposed assignment of quality flags to give some * idea of the scheme. * * NetCDF Floater Old * quality (blank) ARGOS ARGOS * ____________________________________________ * 9 (high) * 8 * 7 1 5 (<2km) * 6 4 (<5km) * 5 (average) 0 2 3 (<10km) * 4 * 3 2 * 2 3 1 (>10km) * 1 (low) * 0 (missing) * * I have purposely left the higher quality flags blank to allow for the * eventual inclusion of even more accurate GPS-based tracking systems * such as might be used on surface drifters. These might have RMS * errors less than a kilometer or even less than 10 meters. * * As mentioned earlier, we would also like to continue indicating how * each variable was processsed. To this end the processing status * indicators are retained pretty much as defined. In the scheme * documented below the position and parameters share a common code while * the velocity is conceptually the same but has a slightly more * specific meaning. * * Code Time/Position/Parameters Velocity * _____________________________________________________________ * 0 Missing Missing * 1 Interpolated Backward difference * 2 Forward difference * 3 Splined Splined * 4 Manual edit Manual edit * 5 Filtered (Averaged) Filtered (Averaged) * (see GLOBAL filter) (see GLOBAL filter) * 9 Original value Original value * * It would be nice if these were not a whole separate field and were * combined with the quality. To achieve this the quality indicator has * been scaled by a factor of 10 (the tens place) and added to the method * indicator in the units place. * * Some examples: * Code 19 Poor, original value * 53 normal, splined * 61 good, interpolated * 73 very good, splined * 01 gap, interpolated * 00 missing value * * Operationally, how does this get implemented? The primary concern is * not really the new ALACE/PALACE data as that is going directly to the * NetCDF format and retains engineering parameters, etc. We are trying * to establish a format that con be used for the conversion of all the * old RAFOS, SOFAR and other floater or drifter format. Thus, where * there was no quality (blank in column 36) an average value should be * assigned. Of course where data was missing and interpolated or * resampled we have no way of knowing what the original quality was * so it will have to be assumed average. Likewise for filling in a * missing value, where the previous point may be bad and the following * point excellent; there is no quantitative way of determining the * quality. * * The problem of gaps are a little different. Gaps arose originally * because an instrument was 'lost' or a parameter sensor 'dropped out'. * These were originally just noted in the processing, and in some cases * the float was divided into segments. Later, when the data transmission * method changed, a flag was added to indicate there was a gap greater * than some threshold (see GLOBAL gap_flag_days) and the values were * subsequently filled in. These will be noted by the quality flag being * 0; thus gaps that are completely missing will be value 00, while * gaps that have been filled in will have values like 01, 03 or 04. * Note that in terms of quantitative value the leading zeros are * superfluous. Legitimate values will therefore always have a value * > 10, the higher the number, up to 99, the better the quality.