## 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