Please note: You are viewing the unstyled version of this website. Either your browser does not support CSS (cascading style sheets) or it has been disabled. Skip navigation.

Data Processing

  Email    Print  PDF  Change text to small (default) Change text to medium Change text to large

Related Files

» Krishfield, R., S. Honjo, T. Takizawa, K. Hatakeyama. IOEB Archived Data Processing and Graphical Results from April 1992 through November 1998. WHOI Tech. Rep. 99-12, Woods Hole, MA, 88 pp., 1999.
PDF file [6.5MB]

IOEBs are deployed in one of the most difficult environments in the world to reach and exist in. These systems are not designed to be expendable, but the extreme cold temperatures and mechanical force of Arctic sea-ice make for greater risk of electrical or mechanical buoy failure than in more moderate climates. By transmitting a subset of the results via satellite we ensure the acquisition of some data, even in the worst circumstances. Ideally, upon recovery of an IOEB, the data transmitted can be augmented by higher resolution stored results. But since the 1992 IOEBs have not yet been recovered, and the 1994 IOEB was recovered without most of its mooring instrumentation, the archived data in this report consists entirely of transmitted data.

Data Acquisition


Every IOEB transmits an ARGOS datastream from two separate PTTs and antenna combinations every 1.5 to 2 minutes while sufficiently powered and operational. Depending on the number of ARGOS satellites, their orbit, and atmospheric conditions, updated data is acquired by ARGOS up to over 28 times per day, per satellite. This data is downlinked at certain spots, and transferred via secondary satellites to ARGOS processing centers in Europe and Maryland. Data is delivered to our laboratory from Service ARGOS in Maryland in two manners: using the Automatic Distribution System (ADS) over the internet, and on floppy disks via the US mail. The ADS system developed by ARGOS accesses our server each day, and downloads a file with all the raw data throughout the previous 24-hour period. The ADS data is the same as the data mailed every month on floppy disk, except that the ADS data is in compressed form to reduce transmission time. The IOEB Archived Data Processing (or IADP) programs discussed below can work either on the smaller daily or monthly files individually, or combinations of these files into multiyear datasets at once. The data presented in this report consists of the all the data collected from the ADS system in 1992-94 combined in a single file called jargos92-94.raw, and all the data on floppy disks from April 1992 through November 1994 combined in a single file called 1016_92-94.raw. Due to trivial reasons neither file is complete, so they are combined together and duplicates removed to provide every correctly acquired data.

Computer hardware configuration


The desktop computer system used to write, compile, and document all the code, drawings, plots, and text described in this report is a PC-compatible 486DX2, with a 66 MHz CPU clock, 16 Mb of memory, and an 1 Gbyte hard disk drive. Subsequent descriptions of operation times are with regard to this system, although the programs could run on systems with less sophisticated hardware with reduced speed. The plots were generated on an Hewlett-Packard Laserjet 4M, with a print resolution of 600 dpi.

OS/2 Operating System and Software requirements: C Compiler, GMT, MKS


The software described in this report was optimized under the IBM OS/2 (Versions 2.1 and later Warp 3.0 with WIN/OS2) multitasking Operating System for PCs (IBM, 1995). However, the source code for all the IADP programs is written in highly portable C language (Kernighan et al., 1988) which facilitates easy translation to alternate platforms. In particular, nearly all the structures and functions should be directly portable to UNIX, except for parts of the directory naming and time structures. In fact, the programs of the Generic Mapping Tools GMT-SYSTEM (Wessel et al., 1991) used to generate all of the plots in this document was ported to OS/2 from UNIX with few difficulties. In addition, the Mortice Kern System (MKS) Toolkit (Version 4.2) of UNIX utilities (MKS, 1993) bridges the gap between platforms; in particular, the MKS sort.exe routine is used in our processing scheme instead of the OS/2 system sort.exe which cannot input the large files. The Borland C++ (Version 1.0) compiler for OS/2 (Borland, 1993) was used throughout for producing the executable programs from the code.

Processing routines


The programs that comprise the IADP system (.exe files) are all intended to be run in either a full screen or partial OS/2 command window, by entering the program name on the command line with operational parameters. If too few parameters are entered, a program will cease immediately and print an error to the screen. Programs also cease when they are unable to open some input or any output files. All of the IADP executable programs provide a means of generating operation logfiles by appending either /s for a short (summary) operation log, or /l for a long (itemized) operation log to the end of the command call. All the text directed at the screen can be redirected to a disk file using the redirection operator > filename to open a new file named filename, or >> filename to append to filename.

To automate a series of operations on the input, batch command files (indicated by filename extensions of .cmd) combine multiple programs and their input parameters in an ASCII text file. Here, batches are used to facilitate both processing and plotting the data. In batch files command line variables are indicated by a percent sign (%) followed by a number, while replaceable variables are indicated with two percent characters (%%) and a character. Some of the simple batch commands with self-evident functions that are used in the IADP scheme include: REM (remark statement), ECHO (to print to screen), CALL (to run another batch file from within a batch file), and FOR (to repetitively call commands with one different parameter). Other useful commands used during the development were: GOTO label (execute next command after label ), and :label (line label indicated by : at beginning).

Batch files iadp.cmd, iadp2.cmd

By combining the various IADP executable programs and command files into batch files, automatic processing of the raw ARGOS data into accurate physical and environmental sensor data occurs. Similarly, postscript representations of all the variables can also be automatically generated using various GMT executable programs in plotting batch files. The input raw ARGOS datafiles described here, cover a period of 41 buoy-months, from April 1992 through December 1994, containing the data from two IOEBs, and exceeded 20 Mb of disk storage in compressed mode and over 75 Mb uncompressed. Running the batch file iadp2.cmd using these input generated another 130 Mb of ASCII data in 1100 files with the fully processed results, and takes over 3 hours to complete on the computer hardware previously described. The GMT Postscript files generated to produce all the plots in the data section, amount to another 10 Mb of filespace.

The first batch command file in Appendix A, iadp.cmd takes as its only argument a single ARGOS datafile and sequentially calls the various IADP executable programs described below to completely process the file and plot the results. The second file in Appendix A, iadp2.cmd takes two files, one being the raw ADS file (compressed), the other the ARGOS distributed disk file (uncompressed), combines the extracted datasets into one with no duplicates, and subsequently performs the same processing and plotting as iadp.cmd. The plots generated by the full execution of iadp2.cmd are presented in Section III.

Extract and sort IOEB data: extrioeb, MKS sort


The first operation performed on the raw ARGOS datafile is the extraction of the IOEB locations and sensor data from ARGOS format into real numerical values. The program extrioeb.exe performs this operation on a single input file; outputting separate location and data files for each PTT number entered during the command call. Only PTT numbers that are configured in the file convjarg.c are supported. The maximum number of PTTs that can be processed by one call to extrioeb is defined at 4 here, but may increased by redefining MAXPTTS in the file extrioeb.h and recompiling. The output files are automatically constructed from the input PTT numbers by appending either lat.ext for locations, or tab.ext for sensor data. The program sequentially reads in a single line of the input file and processes the information, until the end-of-file is reached. There are no input parameters to delineate timelimits at this stage of the processing. Detailed or summary descriptions of the operation are printed to the screen by appending either /l or /s to the command call, or may be redirected to a disk file by further using the redirection operator > in conjunction with an output filename.

A sample command call to extract IOEB data from file input.raw for PTTs 1, 2, 3, and 4, with summary operations recorded in file ops.log would be:

extrioeb input.raw 1 2 3 4 /s > ops.log

The input file may be in either compressed or uncompressed ARGOS PRV formats. In our example, eight output files (besides the logfile) would be generated: 1lat.ext, 1tab.ext, 2lat.ext, 2tab.ext, 3lat.ext, 3tab.ext, 4lat.ext, and 4tab.ext. Each lat.ext file consists of 8 columns of location data: ARGOS program number, PTT number, date code, time code, ARGOS location quality, longitude (east positive), latitude (north positive), NOAA satellite letter, and PTT frequency in MHz. Each tab.ext file consists of a variable number of columns of sensor data, depending on the buoy sensor configuration and sequence number. However the first six columns always contain the data record information: ARGOS program number, PTT number, date code, time code, number of consecutive repetitions received by the ARGOS satellite with the same data, and the IOEB sequence number. The remaining columns (up to 59) contain the individual IOEB sensor variables as determined by the particular sequence number. Table 1 indicates the sensor variables assign each columns depending on the sequence number.

                    Table 1

                 Sequence Number
    Column    1    2    3    4    5    6    


      7    MBV    TR    MBV    TR    MBV    TR


      8    MD    FL    MD    FL    MD    FL


      9    MTIM    SC0T    MTIM    SC0T    MTIM    SC0T


     10    MHE    SC0C    MHE    SC0C    MHE    SC0C


     11    MTX    SC0S    MTX    SC0S    MTX    SC0S


     12    MTY    SCDO    MTY    SCDO    MTY    SCDO


     13    MBAR    SCFL    MBAR    SCFL    MBAR    SCFL


     14    MWS    SC1T    MWS    SC2T    MWS    S4N


     15    MWD    SC1C    MWD    SC2C    MWD    S4E


     16    MAT    SC1S    MAT    SC2S    MAT    S4T


     17    MTAVG    ST    MTAVG    WTSS    MTAVG    S4C


     18    IBV    (AnCT)    MTSTD    WTSE    MTSTD    S4S


     19    IDA    (AnBF)    IECH    (AnCT)    PTTn    (AnCT)


     20    ITIM    (AnQ1)    IS1A    (AnBF)    CONn    (AnBF)


     21    IS1A    (AnQ2)    IS1B    (AnQ1)    IS1A    (AnQ1)


     22    IS1B    (AnQ3)    IS2A    (AnQ2)    IS1B    (AnQ2)


     23    IS2A    (AnQ4)    IS2B    (AnQ3)    IS2A    (AnQ3)


     24    IS2B    (AnQ5)    IS3A    (AnQ4)    IS2B    (AnQ4)


     25    IS3A    (AnX4)    IS3B    (AnQ5)    IS3A    (AnQ5)


     26    IS3B    (AnX3)    IT01    (AnX4)    IS3B    (AnX4)


     27    IT01    (AnX2)    IT02    (AnX3)    IT01    (AnX3)


     28    IT02    (AnX1)    IT03    (AnX2)    IT02    (AnX2)


     29    IT03    (AnT)    IT04    (AnX1)    IT03    (AnX1)


     30    IT04    (AnEN)    IT05    (AnT)    IT04    (AnT)


     31    IT05    (AnTV)    IT06    (AnEN)    IT05    (AnEN)


     32    IT06    (AnHV)    IT07    (AnTV)    IT06    (AnTV)


     33    IT07    (AnE1)    IT08    (AnHV)    IT07    (AnHV)


     34    IT08    (AnE2)    IT09    (AnE1)    IT08    (AnE1)


     35    IT09    (AnE3)    IT10    (AnE2)    IT09    (AnE2)


     36    IT10    (AnE4)    IT11    (AnE3)    IT10    (AnE3)


     37    IT11    (AnE5)    IT12    (AnE4)    IT11    (AnE4)


     38    IT12    (AnN1)    IT13    (AnE5)    IT12    (AnE5)


     39    IT13    (AnN2)    IT14    (AnN1)    IT13    (AnN1)


     40    IT14    (AnN3)    IT15    (AnN2)    IT14    (AnN2)


     41    IT15    (AnN4)    IT16    (AnN3)    IT15    (AnN3)


     42    IT16    (AnN5)    IT17    (AnN4)    IT16    (AnN4)


     43    IT17    (AnV1)    IT18    (AnN5)    IT17    (AnN5)


     44    IT18    (AnV2)    IT19    (AnV1)    IT18    (AnV1)


     45    IT19    (AnV3)    IT20    (AnV2)    IT19    (AnV2)


     46    IT20    (AnV4)    IT21    (AnV3)    IT20    (AnV3)


     47    IT21    (AnV5)    IT22    (AnV4)    IT21    (AnV4)


     48    IT22        IT23    (AnV5)    IT22    (AnV5)


     49    IT23        IT24        IT23


     50    IT24        IT25        IT24


     51    IT25        IT26        IT25


     52    IT26        IT27        IT26


     53    IT27        IT28        IT27


     54    IT28        IT29        IT28


     55    IT29        IT30        IT29


     56    IT30        IT31        IT30


     57    IT31        IT32        IT31


     58    IT32        IT33        IT32


     59    IT33                IT33



Extrioeb loops through the input files by reading in a record as a string, and then performs a series of parses and checks to load the information into a record structure. The location data is treated separately from the sensor data. Since data from and ADCP is acquired from only one of the IOEB buoys, the ADCP parse functions are run and ADCP variables output, only if a match is made with the PTT number. Otherwise records are scanned according to data format in Table 1. The output format of each variable is dependent on the resolution of the particular sensor. Records with sequence numbers of 0 or 7 are eliminated, as are records with zeros loaded in every raw hex value. If an input error is encountered anywhere, this information is available for logging, and the program continues back to the beginning of the loop.

Depending on the PTT number, extrioeb calls functions in convjarg.c to scale each data variable according to buoy specific information and calibrations. Convjarg.c in turn calls functions in prosens.c which are variable specific routines to process each particular sensor value. The program is intended to be expandable to include new PTTs and sensors from future IOEB buoys.

Process location timeseries: sctrioeb, intrioeb, cotrioeb, smtrioeb

Four separate programs are used to convert the extracted IOEB locations to a smoothed interpolated drift track with a standard error of less than 200 m per location. The order of the operations is:

sctrioeb.exe (in PTT location file) (out PTT location file) (std number) [/s or /l]
which screens the locations using a Gaussian filter for first differences exceeding a given number of times the standard deviation (std).

intrioeb.exe (in PTT location file) (out PTT location file) [/s or /l]
which interpolates the locations to an 1 hour interval.

cotrioeb.exe (in PTT0 location file) (in PTT1 location file) (out buoy location file) [/s or /l]
which combines the interpolated locations from separate PTTs into one IOEB buoy drift track.

smtrioeb.exe (in buoy location file) (out buoy file .ext) (start year) [(end year) /s or /l]
which smoothes the drift using a 6-hour triangular filter, computes the Earth-corrected speed vectors of the drift and the geomagnetic declination, and outputs the results to separate files for each variable, and for each year, along with several files for plotting purposes.

Each program is capable of outputting the operation results to a monitor or disk file, in the same manner as described earlier. The first two programs output PTT location files with the same column and number format as are input: ARGOS program number, PTT number, date code, time code, ARGOS location quality, longitude (east positive), latitude (north positive), NOAA satellite letter, and PTT frequency in MHz. The combined drift track is similar to the above, with the omission of the last two columns, which have no meaning when combined. The files output after smoothing are with few exceptions two-column timeseries which includes the decimal day of the year (with fractional time) in the first column, and a value in the second. Day of the year extends from 1 to < 366 on non-leap years, and to < 367 on leap years. The calculated speeds include the Earths curvature, while the geomagnetic declination is based on the program GEOMAG.FOR from the National Geophysical Data Center (NGDC). Based on the IGRF90 model, this program outputs seven magnetic field parameters, including the magnetic variation with an stated accuracy of ~1/2 degree. A positive angle means that the horizontal component of the geomagnetic field is east (clockwise rotation) of true north. Files with speed vectors or text data for plotting using GMT generally have more than two columns, being generated according to certain generic plotting designs.

Process data timeseries: prefioeb, combioeb, outioeb

Three programs are used to prefilter, combine, and output the extracted IOEB sensor data into multiple separate timeseries of each data variable per buoy. These operations are accomplished by:

prefioeb.exe (in PTT data file) (out PTT data file) [/s or /l]
which prefilters and timecodes the sensor data without regard to the actual sensor meanings.

combioeb.exe (in PTT0 data file) (in PTT1 data file) (out buoy data file) [/s or /l]
which combines the prefiltered data from separate PTTs into one IOEB datafile, while checking for NULL data values and other errors.

outioeb.exe (in buoy data file) (out buoy file .ext) (start year) [(end year) /s or /l]
which outputs separate files for each sensor variable, and for each year.

Each program is capable of outputting the operation results to a monitor or disk file, in the same manner as described earlier. The output format of the prefiltered data is the same as input: ARGOS program number, PTT number, date code, time code, number of consecutive repetitions received by the ARGOS satellite with the same data, the IOEB sequence number, and up to 59 columns of data. Each record of data after the sequence number is treated as a single string for comparison purpose, and like strings are combined if they are merely repetitions within a certain timelimit. In the end, only one record is saved for each series of scans in a new data sequence, according to the accumulated number of repetitions. If only 1 accumulated repetition exists for a particular data sequence, then that data usually includes broadcast noise and is not included. Each data scan has its acquisition time determined from a simultaneous determination of interpolated controller sequence shifting times.

As prefioeb inputs the sensor data, it tracks all moments when the IOEB MCU controller switches to next sequence within a two minute timeperiod which an ARGOS satellite was actively monitoring the buoy. This rather complicated scheme is necessary, because not all instruments broadcast a timecode, and the MCU controllers do not switch sequences at an exact hourly interval, but varies slightly. The accuracy of the acquisition time coding becomes extremely important when removing the drift of the buoy from observed speeds detected by some sensors. The results show that the method of time coding applied by prefioeb appears to work very well.

Combioeb takes data from both PTTs on a single buoy, flags the NULL values and outputs the best dataset to a single file. The first five columns output contain the same format as the prefiltered input. However, the sensor data output is standardized so that an IOEB without an ADCP will have 81 additional columns of sensor data, while one with will have 141 additional columns, where column represents a separate data variable. When combioeb reads in a record from a PTT data file, it parses each data item separately and loads it into a sensor dependent position in the floating-point data array. Array variable 0 is written to column 6 of the output file when processed, and each next variable incrementally thereafter. Table 2 indicates the sensor variables assigned to each array number:

                     Table 2

  Array Nos.    Variables                                


   0-12       MBV, MD, MTIM, MHE, MTX, MTY, MBAR, MWS, MWD, MAT, MTAV, MTMX, MTST    


   13-16      PTT0,CON0,PTT1,CON1    


   17-20      IBV,IDAY,IHR,IECH


   21-26      IS1A,IS1B,IS2A,IS2B,IS3A,IS3B


   27-59      IT01-IT33


   60-61      TR,FL


   62-66      SC0T,SC0C,SC0S,SCDO,SCFL


   67-69      SC1T,SC1C,SC1S


   70-72      SC2T,SC2C,SC2S


   73-77      S4N,S4E,S4T,S4C,S4S


   78-80      ST,WTSS,WTSE


if ADCP:


   81-95      A0CT,A0BF,A0Q1-5,A0X4-1,A0T,A0EN,A0TV,A0HV


   96-110     A0E1-A0E5, A0N1-A0N5, A0V1-A0V5


   111-125    A1CT,A1BF,A1Q1-5,A1X4-1,A1T,A1EN,A1TV,A1HV


   126-140    A1E1-A1E5, A1N1-A1N5, A1V1-A1V5



Each data group is separately checked for NULL values and all zeros by specific functions within combioeb. All IADP programs assign a value of -9999.999 to NODATA for NULL points.
Outioeb simply loops through the combined buoy datafile once for each sensor variable and outputs a separate two column for each variable for each year, which includes the decimal day of the year (with fractional time) in the first column, and a value in the second. NULL values are not output. The include file outfile.h contains the names array used to build the output filenames from the variable number. This program is the slowest program in the IADP suite of programs, especially for large input files.

Adjust data for drift: adjioeb

After the location data has been processed into a smooth hourly interpolated series, and the sensor data prefiltered and output, then specific corrections can be applied to selected variables to remove the effects of the buoy drift speed and geomagnetic declination. This applies to the wind monitor data, ocean current data, and compass data. These adjustments are performed by the program adjioeb.exe, which additionally calculates the combined magnitude of apex tilt from the x and components, and corrects (roughly) for an error is data collection software of the 1992 BGY IOEB barometer data.
There are three steps in the correction procedure that needs to be made to the raw transmitted IOEB wind monitor data to convert it to true wind? velocity referenced in an x-y plane. The first step consists of all the mechanical and electronic adjustments that are performed to reference the wind direction to geomagnetic north. The second step applies the geomagnetic correction to provide a result referenced to true (or Earths) north. Finally, to provide output that can be directly compared to simultaneous ice drift and ocean velocity data (also provided by the same IOEB), the third step changes from an Earth referenced to an x-y coordinate system to indicate the direction and compute the individual component vectors. To simplify the calculations, in all circumstances the direction that the wind travels will be considered in the oceanographic sense, rather than in the more common meteorological sense. This means that a wind current of 180 will be considered to head toward the south (oceanographic sense), instead of coming from the south (meteorological sense). This is generally how the directions of ice drift and ocean currents are portrayed, thus facilitating direct comparisons. In addition, all our calculations assume the units of degrees, instead of radians.

Electronically, the IOEB raw wind direction measurement represents the output from a variable resistor controlled by the mechanical wind vane. Conditioning electronics supplied by the sensors manufacturer output a very precise voltage between 0 and 5 V, proportional to the direction. Ten times during the first ten minutes of every hour, the analog signal output from the wind monitor is digitized and temporarily stored. The ensemble is averaged and the result output by the meteorological data logger module to each microcontroller unit. Via ARGOS transmitters, the raw wind direction is transmitted as an 8-bit number, which represents values between 0 and 360 , resolving each 1.4 . It is this raw wind direction that is received in our laboratory and used to determine the real wind direction.

As an IOEB drifts, the surface apex is free to rotate and consequently, the mast securing the wind monitor also rotates. A magnetic compass located in the apex measures this rotation with respect to geomagnetic north. Consequently, to derive geomagnetically referenced wind direction, the magnetic compass measurement must be added to the raw IOEB wind direction. Furthermore, for mechanical mounting purposes, the magnetic compass and wind monitor are offset by 40 , requiring the subtraction of this value from the above. Using wd for raw wind direction, and wdc for corrected wind direction, we can write the first step of the wind direction correction in equation form as:

wdc = wd + compass - 40

The second step of the correction involves correcting for the geomagnetic declination which changes over time, and as the location of the IOEB changes. We incorporate an algorithm from the National Geophysical Data Center in Boulder, Colorado called IGRF90 into our processing routines which returns the angle of declination in degrees based on the year and the drift location of the IOEB. This declination is added to our previous corrected wind direction:
wdc = wd + compass - 40 + declination

This result is sufficient to describe the direction of the wind in terms of true? geomagnetic north, but to determine the north and east components, conversion to an x-y coordinate system is preferred.
Changing coordinate systems in effect changes the intercept and direction of rotation of the wind vectors in vector space. Whereas the geophysical system is oriented with 0 upward (or north) and increase clockwise, mathematical systems generally orient 0 to the right (or east) and increase counter- clockwise. In sum, subtracting the direction in the geophysical sense from 90 , converts to the angle to the mathematical sense. This makes the resultant wind correction equation:

wdc = 90 - (wd + compass - 40 + declination)

or
wdc = -wd - compass - declination + 130

From the raw wind speed (ws) and the corrected wind direction, wind components in the horizontal and vertical directions can be computed:

wx = ws * cos(wdc)
wy = ws * sin(wdc)


In most cases, the above equations are sufficient to describe the velocity of the wind. Since the IOEB is drifting, however, the movement of the buoy affects the apparent wind measured by the wind monitor. Because the drift speed is usually less than one-tenth of the wind speed, it can be neglected, but for increased accuracy we account for it by adding the components of drift to the corresponding components of the wind. Using Ux and Uy to represent the components of the IOEB drift, and Wx and Wy to represent the resultant wind components we determine the final absolute wind values:

Wx = ws * cos(wdc) + Ux
Wy = ws * sin(wdc) + Uy

and by geometry:
Ws = sqrt(Wx2 + Wy2)
Wd = arctan(Wy/Wx)


The instruments that measure ocean currents on the IOEB each contain their own compass and transmit Earth referenced vectors of the detected currents. Consequently, the geomagnetic declination needs to be removed, as does the buoy drift. Similar to the process described for the wind, the declination is added to the current direction computed from the east and north vectors, the vector components recomputed, and the drift speed added. Maintaining both meteorological and oceanographic traditions, ocean (and ice) currents are described in the opposite direction from wind currents. Whereas, the buoy (and icefloe) drift speed is an order of magnitude less than the wind speed, it is frequently the same order as the ocean currents thus absolutely requiring removal for any meaningful results. Due to the 150m ARGOS positioning error, however, we have determined that the calculated ocean vectors still have an uncertainty of 2 to 3 cm/s. This is rather large compared to typical Arctic abyssal currents, but is still useful for detecting higher energy disturbances, such as eddies.

Whereas the determination of the magnitude is a straightforward calculation, the correction for the barometer of the 1992 BGY is not. The raw data stored in the Meteorological Module of this particular IOEB is influenced by the tilt y data. Consequently, when the tilt y sensor is slightly positive, the barometer is biased +32. When tilt y is slightly negative, it has no effect. Otherwise, its effect cannot be reasonably determined. Because tilt y is not being broadcast due to the same software error, determining exactly when and how the data is being influenced is impossible. In order to retain some of the information from this barometer, however, we matched the transmitted to barometer charts from the same time period to determine which correction factor to apply. Furthermore, the barometer data is omitted whenever the tilt x sensor indicates any tilt, because of the increased uncertainty.

Screen data for bad points: scrn_b92.cmd, scrn_t94.cmd, scrndata

The final step employed in the IADP scheme is the screening of extreme outlying points in each timeseries of sensor data, using a Gaussian (normal) filter on the first difference. The program scndata.exe was developed to employ a n-sigma cutoff filter on a series, within a given time interval (within one year). For polar degree data, a vector form called scrnpdat.exe performs the same function. Besides the input and output filenames, the time interval (entered in year, and day of year for both start and end times) is included with the command call, as is the cutoff sigma number (usually 4 in this report). Because different sensors on IOEBs operate for different times, a unique batch command file for each buoy is used to repetitively call either scrndata or scrnpdat with different arguments, once for each sensor to be screened per year. Also included in the command file, a number of calculating programs compute speeds, directions, and vector components from indicated files (calcsd.exe, calcuv.exe, calcvec.exe, calcdens.exe). Finally, three matching programs compare input timeseries to for different variations of removing data with unmatching timecodes between files (match1ts.exe, match2ts.exe, matchxts.exe).

Plotting routines


The GMT-SYSTEM (Version 2.1) is used to create all the plots in this report. In this context, GMT stands for Generic Mapping Tools, and is a free, public domain software package available over the Internet (ref. Wessel et al., 1991). It is designed to manipulate columns of tabular data, time-series, and gridded data sets, and display these data in numerous forms, ranging from simple x-y plots to maps and color, perspective, and shaded-relief illustrations. Output is in the Postscript language (Adobe, 1990), which is a versatile language for printing to a large number of devices. Written in the the C programming language as a set of UNIX tools, it was recompiled to operate under OS/2 with only minor modifications. Recently, an updated GMT Version 3 has also become available over the Internet.

The batch files b92_plot.cmd and t94_plot.cmd are used to plot all the data for the 1992 BGY and 1994 TPD IOEB during the years 1992 through 1994. Some of the command files which are called by these particular batch files are generic plotting routines which plot subsets of the IOEB sensor data, while others are specific to only one buoy. With one exception, all the data presented was screened with a 4- sigma cutoff. The 92 BGY ice data was screened with a 0.5-sigma cutoff, but still retains alot of noise. The noise in this data is attributed to a hardware error with certain sensors on the 1992 BGY IOEB network which created glitches during the first two months of operation. The correction of this problem is evident on the 1994 TPD IOEB, where similar ice data was screened with a 4-sigma cutoff, without any apparent glitches.

The drift tracks are plotted on a polar sterographic projection map, with superimposed coastlines, bathymetry, and text. Both the coastline (World Data Bank II) and bathymetry (ETOPO-5) data are from the NGDC. The remainder of the plots are straightforward x-y representations of the timeseries data. The x (time) scaling is uniform, to allow visual comparison between different data. In some cases the y scales are non-uniform or nonlinear, in order to highlight specific features of the data.

Processing Batch Files


iadp.cmd     Performs all data processing on a single IOEB raw datafile.
iadp2.cmd    Performs two-file data processing on IOEB data.

Program Code Dependencies


extrioeb.exe = extrioeb.h, extrioeb.c, convjarg.c, prosens.c, sc_cnv.c
sctrioeb.exe = sctrioeb.c

intrioeb.exe = intrioeb.c

cotrioeb.exe = cotrioeb.c

smtrioeb.exe = smtrioeb.c, gm90fun.c

prefioeb.exe = prefioeb.h, prefioeb.c, prefun.c

combioeb.exe = combioeb.h, combioeb.c, combfun.c

outioeb.exe = outfile.h, outioeb.c

adjioeb.exe = adjioeb.h, adjioeb.c, adjfun.c

scrn_b92.cmd, scrn_t94.cmd = scrndata.c, scrnpdat.c, calcdens.c, calcsd.c, calcuv.c, calcvec.c, match1ts.c, match2ts.c, matchxts.c

Operation Summary Files


iadpexta.log     Extraction of raw data from ARGOS disk files.

iadpextb.log 
    Extraction of raw data from ADS network files.

iadp_b92.log     IADP processing of 1992 Beaufort Gyre IOEB data.

scrn_b92.log     IADP batch screening of 1992 Beaufort Gyre data.

iadp_t94.log     IADP processing of 1994 Transpolar Drift IOEB data.

scrn_t94.log     IADP batch screening of 1994 Transpolar Drift data.

Plotfile Dependencies


b92_plot.cmd     Plots all processed raw data from 1992 Beaufort Gyre IOEB.
t94_plot.cmd     Plots all processed raw data from 1994 Transpolar Drift IOEB.

b92_plot.cmd = b92_drif.cmd, b92_l92.cmd, b92_l93.cmd, b92_l94.cmd, iadp_spd.cmd, b92_spdx.cmd, b92_met.cmd, b92_metx.cmd, iadp_wnd.cmd, iadp_it.cmd, iadp_is.cmd, iadp_ctd.cmd, b92_oce.cmd, b92_acp0.cmd, b92_acp1.cmd, b92_acpx.cmd

t94_plot.cmd = t94_drif.cmd, t94_lat.cmd, iadp_spd.cmd, t94_met.cmd, iadp_wnd.cmd, iadp_it.cmd, iadp_is.cmd, iadp_ctd.cmd, t94_oce.cmd


Last updated: March 18, 2009
 


whoi logo

Copyright ©2007 Woods Hole Oceanographic Institution, All Rights Reserved, Privacy Policy.
Problems or questions about the site, please contact webdev@whoi.edu