MLOC xdat file

~.xdat File

This page deals with the ~.xdat file that is read as input to the xdat utility code, one of several utility codes that assist in the cleaning process of an mloc relocation analysis.

Most arrival time datasets contain readings that cannot be usefully employed in a relocation analysis, for a variety of reasons:

  • The pick was made on a noise signal rather than a true phase arrival.
  • The pick was made on a phase arrival from a different event.
  • The station coordinates are grossly wrong.
  • The phase was mis-identified.
  • The phase name is not one for which mloc can calculate a theoretical arrival time.
  • Coordinates cannot be obtained for the reported station code.

The first four cases result in a reading having a large residual against the theoretical arrival time (the others are dealt with elsewhere). All earthquake location codes make some provision to deal with gross outliers. This can be extremely simple, e.g., any reading with a residual greater than N seconds is dropped. mloc employs a more complex algorithm to deal with gross outliers, driven by the wind command. Readings that fail the windowing criteria are dropped from the current run of mloc (listed in the “BAD DATA” section of the ~.phase_data output file with “PRES” in the column “Why Bad”), but under some circumstances they can fall back into a subsequent run as gross outliers unless they are flagged. Those readings are also listed in the ~.xdat output file.

The user seldom needs to look at the ~.xdat file. The only question is whether or not it is appropriate to run xdat after a given run of mloc. It is usually desirable to run xdat at least once early in the analysis, as there will normally be a large number of entries in the ~.xdat file, but in later runs there will be few entries, and often the file will be empty.

The format of the ~.xdat file is kept simple, as it is only meant as input for xdat, i.e., it really only needs to carry the file name and line number that will be flagged. The format is documented in the code module mlocout_phase_data.f90. Here is an example:

  7  COP   ISC      XS          71 x 19670517.0428.50.mnf
 15  PYA   ISC      Sn          15 x 19761128.1113.23.mnf
 39  KER   ISC      Pg          28 x 19990219.1800.10.mnf
 41  MLTT  ISC      Sn          35 x 20020228.0046.31.mnf
 41  ZALF  ISC      Sn          50 x 20020228.0046.31.mnf
 41  SALA  ISC      Sn          64 x 20020228.0046.31.mnf
 43  ASAO  IIEES    Sn          11 x 20030811.2012.06.mnf
 55  VRNZ  ISC      Pn          36 x 20060729.0151.11.mnf
 60  BHD   ISC      Sg          89 x 20090310.1313.02.mnf
 61  IBDR  ISC      Sn         179 x 20090705.2348.25.mnf
 66  HOPEN ISC      IVmB_BB   1977 x 20111023.1041.23.mnf
 66  MTDJ  ISC      Pdif      3943 x 20111023.1041.23.mnf
 74  COAL  ISC      P          312 x 20111029.2224.24.mnf
 75  RAYN  ISC      Sn         436 x 20111106.0243.14.mnf
103  KIEV  ISC                  87 x 20200318.2307.22.mnf

The phase name listed here is the one that was read in from the event file, not the result of any phase re-identification done by mloc. In the example the reading from station HOPEN from event 66 should have been caught by mloc’s algorithm to identify readings that are not legitimate phase arrivals (and flagged with “p”), but in this case an amplitude measurement slipped through.