Step 16: Obtain interseismic GPS velocities and put into .gps format
Global Positioning System (GPS) measurements of benchmark positions have become
so precise that, after about a decade of continuous recording, they can
determine the relative horizontal velocities of benchmarks with precisions as
small as ±0.1 mm/a.
These precise horizontal relative velocities are revolutionizing the fields of
neotectonics and seismic hazard.
In 2013, the major agencies involved in US seismic hazard studies (USGS, CGS,
CEA, & SCEC) collaborated on neotectonic modelling (including NeoKinema
modelling) that made systematic use of GPS velocities for the first time [Field et al., 2013].
You should definitely try to obtain GPS velocities within your study area to
incorporate in your NeoKinema models.
Ask your geodesist friends about work-in-progress, and also check the
geophysical literature for recent solutions.
(Note that a “solution” is preferable to a “compilation.” A compilation
may just bring together velocities for different benchmarks from different
published studies, meaning that there will be small differences in the
assumptions, orbit-models, reference-frames, and software used. These
will translate into small inconsistencies between different velocities which
will introduce fictitious strain-rates. A “solution” implies that many
benchmarks have been analyzed as a group, going back to their original
histories of antenna-to-satellite range measurements, in order to obtain the
best uniform models of clock-corrections, orbit errors, ionospheric effects,
hardware changes, and software changes.)
When you obtain a solution covering your study area, it will usually be in
the form of a table, with benchmark names, positions, horizontal velocity
components, and uncertainties.
There are at least 3 considerations involved in getting these ready for use in NeoKinema:
(1) Formatting; (2) Reference-frame; and (3) Time-windows
We will look at formatting first, because once that is done I can offer some
utility programs to assist with other issues.
Formatting
In this sub-step the goal is to transform the data table into my .gps format, which is documented here.
Typically it will be necessary to re-order some of the columns in the table.
(If there are columns that seem unnecessary, such as vertical velocity
components or time-window of observation, it may be best to move these far to
the right of the table, but not delete them.)
It may also be necessary to change units:
If velocity components and/or uncertainties are in (SI) units of m/s, these
will need to be transformed to mm/a.
If geographic coordinates were reported in degrees-minutes-seconds, it will be
necessary to convert these to decimal degrees.
For any of these purposes, the easiest path is to import the data into a spreadsheet program, such as Microsoft Excel or Apache OpenOffice Calc.
As we have discussed before (Step 11), it is
not difficult to re-order columns in a spreadsheet.
Just right-click on the built-in column headers (A, B, C, …) and use Insert,
Copy, Paste, and finally Delete.
Multiplying figures in one column by a constant is a bit more complex,
because you have to insert TWO new columns.
Then, fill one of the new columns with (identical) formulas giving the desired
result.
Then, Copy these desired results and Paste Special / as Values into the second
new column.
NOW you will be able to Delete the 2 source columns that are no longer wanted.
Once your reformatted table is finished (and Save-d in proprietary
spreadsheet format, such as .docx for Excel),
the process for converting it to plain-ASCII flat-file .gps format is
exactly parallel to the procedure in the previous Step.
(One small difference is that .gps format includes an extra line of text
at the top, which is not present in f*.nki format.)
During this reformatting process, you may be tempted to sort the benchmarks
(rows), or delete some benchmarks (rows).
PLEASE DO NOT DELETE OR RE-ORDER ANY BENCHMARKS AT THIS TIME.
This option will be discussed further in the next Step.
Reference-frame
Horizontal velocities would be meaningless without a reference; some rigid framework must be “held fixed” and assumed not to move (even though physics tells us that this choice is arbitrary).
Every GPS solution has a clearly-identified “velocity reference frame” (which is an object-identifying name, not a number!). It might be:
1.
The rigid portion of a tectonic plate adjacent to your study area.
(For example, GPS velocities in the deforming western US are frequently
expressed relative to “stable NA” or “stable North America plate” which lies to
the East.
GPS velocities in the deforming southern parts of Europe are frequently
expressed relative to “stable EU” or “stable Eurasia plate” which lies to the
Northeast.)
This is the ideal case for NeoKinema modeling; you can simply adopt this
velocity reference frame for your whole study (in Step
25, later).
2.
The rigid portion of some other plate (not adjacent to your study area).
In this case, it will probably be best to transform all the GPS velocities to a
different reference frame that IS adjacent, and which you can adopt as
the reference frame for your whole study.
You can transform velocities in .gps format from one reference frame to
another with my utility program ReframeGPS.
This program will ask you to input the 3 parameters (North-latitude,
East-longitude, rotation-rate) of the Euler vector that describes the rotation
you want to add to all the velocities.
(For example, to convert .gps velocities from NA-fixed to PA-fixed, you
would add the rotation-rate of NA with respect to PA.)
There are many possible source of such “Euler poles” or “Euler vectors” in the
literature; one possible source is Table 1 in Bird [2003].
Tip #1: If your source does not give the Euler vector for the plate-pair you
need, perhaps it gives the Euler vectors of both plates with respect to a
common third plate?
For example,
Table 1 of Bird [2003] gives rotation-rates of all
plates with respect to PA.
In that case,
you can run ReframeGPS twice; the first time to convert to the common (e.g.,
PA-fixed) reference frame; the second time to complete your transformation.
Tip #2: Whenever you need to subtract a rotation-rate, you negate the
Euler vector (that you found in the literature) by negating its
rotation-rate. Do NOT negate its latitude and longitude!
Tip #3: If you worry that the frame-changing Euler vector that you are adding
has its own error—You are right! Hold that thought! There will be
an opportunity to add some reference-frame uncertainty in Step 19.
3.
An abstract reference frame such as International Terrestrial Reference
Frame (ITRF) which is not fixed with respect to as any rigid plate.
In this case, the best option is probably to “pretend that ITRF is a plate” and
search the literature for an Euler vector that gives the rotation-rate of your
preferred (local) rigid plate with respect to ITRF, or vice-versa.
Once you have that Euler vector, you can add or subtract it with my program ReframeGPS, as described in the paragraph
above.
However, my programs ALSO offer the option to treat the GPS velocity
reference-frame as “unknown” or “free-floating”. This will be discussed
in Step 19.
Time-windows
Each benchmark that has been tracked with GPS has a (fixed) date of first-position-determination. (Sometimes, with benefit of hindsight, we might substitute a later date of the “first-accurate-position.”)
Each benchmark also has a date of last-position-determination used in a
particular solution (even if that benchmark continues to be observed
today).
If a large earthquake has occurred near a certain benchmark, the creator of the
GPS velocity solution may have decided to omit data from times during and after
the earthquake. (That would be ideal.)
The time-interval between first and last position determinations is the time-window for the average horizontal velocity reported in the .gps file. Time-windows are often different for different benchmarks in the same file.
For purposes of NeoKinema modeling, what we want are observations of
steady interseismic velocity, unaffected by earthquakes or other
time-dependent “noise” sources (whether man-made or natural).
Ideally, each component of the benchmark position, when plotted against time,
should yield a (somewhat noisy) straight-line graph.
Since benchmarks can move by several meters during a great earthquake, and then move as much as 50% more in the years-long period of postseismic relaxation, the inclusion of any large earthquake in the time-window for any benchmark would be very unfortunate for our purposes.
As you read about the details of the GPS velocity solution you are using,
attempt to determine whether its creator shared this concern, and whether they
have already edited-out benchmarks (and/or time-windows) affected by nearby,
large, shallow earthquakes?
If not, then you may need to do so. (You will not have the tools needed
to edit-out parts of the time-window, so in practice you will have to edit-out
the entire benchmark from your NeoKinema study.)
HOWEVER, AT THIS TIME YOU SHOULD ONLY NOTE QUESTIONABLE BENCHMARKS, AND NOT
REMOVE THEM YET.
Removing them too early could destroy the opportunity to make use of an
existing “GPS covariance matrix”, as explained in the next
Step.