NAME
x_system - A Cross-Over Error Analysis Tool
INTRODUCTION
The x_system was developed to aid in the task of gridding geo-
physical track data, e.g. gravity, magnetics, or bathymetry. It has
long been recognized that although the data quality along track may be
quite good, one usually finds discrepancies at the points where two
tracks intersect. These cross-over errors (COE) can be large enough to
cause artificial features in the final gridded dataset, which would
render geological interpretations of such a map questionable. Also,
notoriously bad cruises will generate high COEs along their tracks, and
should ideally be removed from the data base before gridding is
attempted. The reasons why COEs arise are many and will not be dealt
with here. Although originally intended to be used for marine gravity
data only, x_system has been designed to handle magnetics and
bathymetry as well. (For an overview of gravity COEs, see Wessel and
Watts [1988]). In most cases, marine gravity COEs can be explained by a
simple model having only 2 parameters. These are a d.c.-shift and a
drift-rate that apply for the duration of the cruise. The goal of the
COE analysis is thus to determine the dc-shifts and drift-rates for
each leg that will minimize the COEs in a least squares sense, and at
the same time flag cruises that exhibit unreasonably high COEs (even
after correction for d.c.-shift/drift). Furthermore, we can also assign
a ’quality index’ for each cruise by looking at the standard deviation
of the COEs. The d.c.-shift/drift rate model may not be as meaningful
for magnetics and bathymetry as it is for gravity. However, looking for
high COEs is still one of the best ways of identifying systematic
errors in the magnetic/bathymetric data sets.
x_system PHILOSOPHY
Since the d.c.-shift/drift corrections for a given cruise
depend entirely on the values of the COEs generated at intersections
with other cruises, there is no such thing as a ’final correction’ as
long as we keep on adding data to the data base. This means that the
system must be able to incorporate new data and compute a new set of
d.c.-shifts/drift-rates that takes the new COEs into account. x_system
is made modular so that one program computes the actual COEs, one pro-
gram archives the COE information, and the remaining programs do vari-
ous tasks like reporting statistics (to flag bad cruises), extracting a
subset of the COE database, and solving for the best fitting
d.c.-shift/drift corrections. This way only the new COEs generated need
to be computed and added to the database before a new correction solu-
tion is sought.
All the 8 programs that make up the x_system package have been
written in the C programming language and are intended to be run on a
UNIX machine. Thus, it is assumed that the user has access to UNIX
tools like awk, grep, and sort, and that the operating system provides
a means for redirecting input/output. Likewise, it is assumed that all
the geophysical data are stored in the GMT-format as outlined in the
GMT MGG supplements man pages, and that the 1 by 1 degree bin informa-
tion files (gmtindex.b and gmtlegs.b) have been created and are being
maintained by the database librarian.
HOW TO DO IT
up a pair will at least once occupy the same 1 by 1 degree bin, and may
thus intersect. Those combinations which do not have any bins in common
obviously don’t have to be checked. Let’s call this list of pairs
xpairs.lis.
x_over is the main program in the package as it is responsible
for locating and computing the COEs For details on algorithm, see Wes-
sel [1989]. It takes two cruise names as arguments and writes out all
the COEs generated between them (if any). Since xpairs.lis may contain
quite a few pairs, the most efficient way of running x_over is to cre-
ate an executable command (batch) file that starts x_over for each
pair. Using awk to do this, we would say:
pratt% awk ’{ printf "x_over -<options> %s %s\n", $1, $2}’
xpairs.lis > xjob
pratt% chmod +x xjob (make it executable)
pratt% xjob > xjob.d &
and relax while xjob is crunching the numbers. This is the time-consum-
ing part of the COE analysis, and on a SUN-3 computer with Floating
Point Accelerator installed we average about 10,000 pairs of
cruises/day. It may pay off to split a huge xjob file into smaller
parts, and call the output files xjob.d1, xjob.d2 etc. Most of the run-
time is taken up by reading the GMT files; when in memory the actual
computations are remarkably fast. The output file xjob.d will now have
all the COE information in ASCII form. For each pair of legs there will
be a header record stating the names of the cruises and their starting
years. The following records up to the next header record (or End-Of-
File) will contain lat, lon, time, value, etc. for each COE found. This
is a temporary file, but it is wise to back it up to tape just in case.
When the x_over part is done, time has come to archive the data
more efficiently than ASCII files. This is done by x_update which rear-
ranges the data and updates the binary data base system. After this
step the xjob.d files can be deleted (presuming they have been backed
up to tape). At this stage we have several options available. We can
list some of the COEs by running x_list, which will extract COEs that
match the options we pass, e.g. we might ask for all the internal COEs
for cruise c2104, and only print out time and gravity COE. See the man
pages for more details. x_report can be run, and will output statistics
for separate cruises, i.e. mean and standard deviation of the COEs for
different data sets (gravity/magnetics/bathymetry). To solve for the
best fitting corrections we would run x_solve_dc_drift. This program
will solve for the d.c.-shift/drift-rates for all cruises, update that
information in the data base system, and create correction tables
(ASCII and/or binary). We have now completed the COE analysis for our
initial GMT data bank.
At some later time, however, we will get a new batch of
cruises. We will then follow the the same recipe and go back and run
x_setup, but this time we will use the -L option so that only the pairs
involving new cruises are returned. Then we would run the remaining
programs exactly as described above.
SEE ALSO
gmt(GMTMANSECTION),
AUTHOR
Man(1) output converted with
man2html