1X_SYSTEM(1) Generic Mapping Tools X_SYSTEM(1)
2
6 x_system - A Cross-Over Error Analysis Tool
7
9 The x_system was developed to aid in the task of gridding geophys‐
10 ical track data, e.g. gravity, magnetics, or bathymetry. It has long
11 been recognized that although the data quality along track may be quite
12 good, one usually finds discrepancies at the points where two tracks
13 intersect. These cross-over errors (COE) can be large enough to cause
14 artificial features in the final gridded dataset, which would render
15 geological interpretations of such a map questionable. Also, notori‐
16 ously bad cruises will generate high COEs along their tracks, and
17 should ideally be removed from the data base before gridding is
18 attempted. The reasons why COEs arise are many and will not be dealt
19 with here. Although originally intended to be used for marine gravity
20 data only, x_system has been designed to handle magnetics and bathyme‐
21 try as well. (For an overview of gravity COEs, see Wessel and Watts
22 [1988]). In most cases, marine gravity COEs can be explained by a sim‐
23 ple model having only 2 parameters. These are a d.c.-shift and a drift-
24 rate that apply for the duration of the cruise. The goal of the COE
25 analysis is thus to determine the dc-shifts and drift-rates for each
26 leg that will minimize the COEs in a least squares sense, and at the
27 same time flag cruises that exhibit unreasonably high COEs (even after
28 correction for d.c.-shift/drift). Furthermore, we can also assign a
29 'quality index' for each cruise by looking at the standard deviation of
30 the COEs. The d.c.-shift/drift rate model may not be as meaningful for
31 magnetics and bathymetry as it is for gravity. However, looking for
32 high COEs is still one of the best ways of identifying systematic
33 errors in the magnetic/bathymetric data sets.
34
36 Since the d.c.-shift/drift corrections for a given cruise depend
37 entirely on the values of the COEs generated at intersections with
38 other cruises, there is no such thing as a 'final correction' as long
39 as we keep on adding data to the data base. This means that the system
40 must be able to incorporate new data and compute a new set of
41 d.c.-shifts/drift-rates that takes the new COEs into account. x_system
42 is made modular so that one program computes the actual COEs, one pro‐
43 gram archives the COE information, and the remaining programs do vari‐
44 ous tasks like reporting statistics (to flag bad cruises), extracting a
45 subset of the COE database, and solving for the best fitting
46 d.c.-shift/drift corrections. This way only the new COEs generated need
47 to be computed and added to the database before a new correction solu‐
48 tion is sought.
49 All the 8 programs that make up the x_system package have been
50 written in the C programming language and are intended to be run on a
51 UNIX machine. Thus, it is assumed that the user has access to UNIX
52 tools like awk, grep, and sort, and that the operating system provides
53 a means for redirecting input/output. Likewise, it is assumed that all
54 the geophysical data are stored in the GMT-format as outlined in the
55 GMT MGG supplements man pages, and that the 1 by 1 degree bin informa‐
56 tion files (gmtindex.b and gmtlegs.b) have been created and are being
57 maintained by the database librarian.
58
60 To illustrate how one would set things up, we will go through the
61 necessary steps and point out usage, useful tricks, and pitfalls. (A
62 more complete description of what exactly each program does can be
63 found in the man pages for each program). We will assume that we ini‐
64 tially have N cruises in our GMT data bank, and that we just have
65 received the x_system package. The first thing to do is to run x_init
66 which will create an empty data base system. This will normally be done
67 only once. With N cruises on our hands we will in the worst case have
68 to compare the N*(N+1)/2 possible pairs. This is where x_setup comes in
69 handy. It will read the 1 by 1 degree bin information files and print
70 out a list of pairs that need to be checked. The two cruises that make
71 up a pair will at least once occupy the same 1 by 1 degree bin, and may
72 thus intersect. Those combinations which do not have any bins in common
73 obviously don't have to be checked. Let's call this list of pairs
74 xpairs.lis.
75 x_over is the main program in the package as it is responsible for
76 locating and computing the COEs For details on algorithm, see Wessel
77 [1989]. It takes two cruise names as arguments and writes out all the
78 COEs generated between them (if any). Since xpairs.lis may contain
79 quite a few pairs, the most efficient way of running x_over is to cre‐
80 ate an executable command (batch) file that starts x_over for each
81 pair. Using awk to do this, we would say:
82 pratt% awk '{ printf "x_over -<options> %s %s\n", $1, $2}'
84 xpairs.lis > xjob
85 pratt% chmod +x xjob (make it executable)
86 pratt% xjob > xjob.d &
87 and relax while xjob is crunching the numbers. This is the time-consum‐
89 ing part of the COE analysis, and on a SUN-3 computer with Floating
90 Point Accelerator installed we average about 10,000 pairs of
91 cruises/day. It may pay off to split a huge xjob file into smaller
92 parts, and call the output files xjob.d1, xjob.d2 etc. Most of the run-
93 time is taken up by reading the GMT files; when in memory the actual
94 computations are remarkably fast. The output file xjob.d will now have
95 all the COE information in ASCII form. For each pair of legs there will
96 be a header record stating the names of the cruises and their starting
97 years. The following records up to the next header record (or End-Of-
98 File) will contain lat, lon, time, value, etc. for each COE found. This
99 is a temporary file, but it is wise to back it up to tape just in case.
100 When the x_over part is done, time has come to archive the data
101 more efficiently than ASCII files. This is done by x_update which rear‐
102 ranges the data and updates the binary data base system. After this
103 step the xjob.d files can be deleted (presuming they have been backed
104 up to tape). At this stage we have several options available. We can
105 list some of the COEs by running x_list, which will extract COEs that
106 match the options we pass, e.g. we might ask for all the internal COEs
107 for cruise c2104, and only print out time and gravity COE. See the man
108 pages for more details. x_report can be run, and will output statistics
109 for separate cruises, i.e. mean and standard deviation of the COEs for
110 different data sets (gravity/magnetics/bathymetry). To solve for the
111 best fitting corrections we would run x_solve_dc_drift. This program
112 will solve for the d.c.-shift/drift-rates for all cruises, update that
113 information in the data base system, and create correction tables
114 (ASCII and/or binary). We have now completed the COE analysis for our
115 initial GMT data bank.
116 At some later time, however, we will get a new batch of cruises.
117 We will then follow the the same recipe and go back and run x_setup,
118 but this time we will use the -L option so that only the pairs involv‐
119 ing new cruises are returned. Then we would run the remaining programs
120 exactly as described above.
121
123 GMT(1),
124
126 Paul Wessel, Lamont-Doherty Geological Observatory, Palisades, NY
127 10964. Wessel, P. XOVER: A Cross-over Error Detector for Track Data,
128 Computers & Geosciences, 15, 333-346.
129 Wessel, P. and A. B. Watts, On the Accuracy of Marine Gravity Measure‐
131 ments, J. Geophys. Res., 93, 393-413, 1988.
132GMT 4.3.1 15 May 2008 X_SYSTEM(1)