G L O B K G L O B K: Reference Manual Reference Manual
G L O B K G L O B K: Reference Manual Reference Manual
G L O B K
Reference Manual
Release 10.6
16 June 2015
2
16 June 2015
iii
Table of Contents
1. Introduction ................................................................................................................. 1
1.1 Description and applications of the software ...................................................... 1
1.2 Overview of globk processing ............................................................................ 3
2. Preparing the Input Files ............................................................................................. 4
2.1 htoglb .................................................................................................................. 4
2.2 apr_file ................................................................................................................ 9
3. Running glred, globk, and glorg ............................................................................... 12
3.1 globk command file........................................................................................... 15
3.2 glorg command file ........................................................................................... 34
3.3 Defining a reference frame for the analysis ...................................................... 38
3.4 Examples for GPS analysis .............................................................................. 40
Testing coordinate repeatabilities .................................................................... 40
Estimating repeatabilities and velocities from several surveys ....................... 43
Use of stochastic noise for stations and orbits ................................................. 45
3.5 Examples of globk and glorg output ................................................................ 48
3.6 Error messages ................................................................................................. 62
globk/glred error messages .............................................................................. 62
glorg error messages ........................................................................................ 64
4. Rapid Protyping of GLOBK solutions ...................................................................... 65
5. Plotting Utilities ........................................................................................................ 70
6. Auxilliary Programs .................................................................................................. 75
6.1 glist .................................................................................................................... 75
6.2 glsave ................................................................................................................ 76
6.3 xysum, blsum, bcsum, ensum, enfit .................................................................. 76
6.4 extract, exbrk..................................................................................................... 80
6.5 getrel ................................................................................................................. 83
6.6 swaph, hfupd, htoh ........................................................................................... 83
6.7 glbtog ................................................................................................................ 85
6.8 glbtosnx ............................................................................................................. 86
6.9 corcom, cvframe, velrot .................................................................................... 87
6.10 plate................................................................................................................. 90
iv
1
1. EINLEITUNG
Globk is a Kalman filter whose primary purpose is to combine solutions from the
processing of primary data from space-geodetic or terrestrial observations. It accepts as
data, or "quasi-observations" the estimates and associated covariance matrices for station
coordinates, earth-rotation parameters, orbital parameters, and source positions generated
from analyses of the primary observations. These primary solutions should be performed
with loose a priori uncertainties assigned to the global parameters, so that constraints can
be applied uniformly in the combined solution. Although globk has been developed as an
interface with GAMIT (for GNSS) and CALC/SOLVE (for VLBI), there is little intrinsic
to this pairing in its structure. We have used globk successfully to combine solution files
generated by other GNSS software (e.g. Bernese and GIPSY), as well as for terrestrial
and SLR observations.
deformation from a combination of space and terrestrial geodetic data, J. Geodesy, 72,
200–214, 1998. The basic algorithms and a description of Kalman filtering are given in
Herring, Davis, and Shapiro, Geodesy by Radio Interferometry: The Application of
Kalman filtering to the analysis of very long baseline interferometry data, J. Geophys.
Res, 95, 12561–12581, 1990.
We use the name "globk" to refer loosely to the ensemble of programs collected in the
/kf ("Kalman filter") directory of our software distribution. The most important of these
are htoglb, which converts the solution files from analysis of primary observations into
binary h-files used by the kf software; globk and its near twin glred, which use these h-
files as input to a Kalman filter to produce a combined solution; and glorg, which applies
generalized constraints to the combined solution Glred differs from globk only in
treating the h-files from each day independently, providing a method for generating
coordinate repeatabilities which is more efficient than a rigorous Kalman back solution
performed by globk. Also included in the /kf suite are programs to plot coordinate or
baseline repeatabilities, compare estimates of coordinates or velocities from different
solutions, and relate velocities to plate rotations.
In the next section we describe briefly the steps involved in obtaining a time series and/or
velocities from quasi-observations using htoglb, glred, globk, and glorg. We then
summarize for experienced users recent changes in the software. Chapter 2 gives details
of file preparation using htoglb. Chapter 3 describes in depth the globk/glred and glorg
commands and gives example command files for common applications. Chapter 4
describes the shell scripts and programs used to plot the time series, and Chapter 5 most
of the auxiliary programs that might be useful in your analysis.
Much of the documentation contained here is available on-line and will be displayed
automatically when you type the name of the program with no arguments. To obtain help
files in this way you need to set (e.g., in .login or .cshrc) an environment variable:
Where mydir is the directory on your system containing com, libraries, kf, gamit, and
help. Omission of this command will cause an error message of the form IOSTAT
error 118 occurred opening <program name.hlp> when you attempt to invoke the help.
If you intend to create SINEX files for distribution outside of your institution, you should
also set a second environment variable
% setenv INSTITUTE my-lab
10 April 2015
3
At the start of processing the analyst has available an ensemble of quasi-observation (h-
or SINEX) files from prior processing of primary data from GPS, VLBI, SLR, or
terrestrial observations. The first step is to convert the ASCII quasi-observation files into
binary h-files that can be read by globk. This is accomplished via the program htoglb,
described in Chapter 2.
For GNSS processing (the main emphasis of this manual), the second step is usually to
run glred for all of the (binary) h-files from a survey or period of continuous observations
to obtain a time series of station coordinates, which can then be plotted and examined for
outliers and the appropriate scaling to obtain reasonable uncertainties. When outliers are
found, you may need to repeat your processing of the primary observations (e.g., using
GAMIT) for certain days or to remove the h-files from these days from further analysis.
Once you have obtained a clean data set, you repeat the processing, this time with globk
instead of glred, to combine the daily h-files into a single h-file that represents your
estimate of station positions for the survey or a period of continuous observations. The
globk estimates themselves are usually produced with loose constraints, but as part of this
run (or separately) you can run glorg to define a reference frame by applying constraints
on the coordinates of a selected group of stations. The script sh_glred, described in the
Introduction to GAMIT/GLOBK manual, combines these initial steps, invoking in turn
htoglb, glred, and plotting of time series.
Once you have estimates (h-files) of station coordinates for continuous observations or
several surveys spanning a year or more, you can run glred and globk again, using these
combined h-files as input to obtain a time series (from glred) and/or estimates of station
velocities (from globk) for the entire period spanned by your data. As with the daily
combinations, the globk estimates are usually obtained with loose constraints, and glorg
is run to impose reference frame constraints. Strategies for obtaining time series and
velocities are discussed in Chapter 4 of Introduction to GAMIT/GLOBK.
Globk does not require any particular directory structure, but the one used by sh_gamit
and sh_glred works well, with the following directories at the same level as the day
directories for your GNSS data:
10 April 2015
4
There are three classes of input to the software: 1) Quasi-observations, or solution files,
are contained in a binary h- or global file which must be created from the output of the
primary processing program (GAMIT, FONDA, etc.). These are produced by program
htoglb, described below. 2) A priori values for station coordinates, satellite initial
conditions and parameters, and Earth orientation values are given in the tables whose
formats are described below. 3) Each of the major programs uses a command file which
specifies controls the type of solution, parameters estimated, and constraints applied.
These are explained in detail in Chapter 3.
2.1 htoglb
This is the program that converts to globk binary h-files the ASCII solution files from a
variety of GNSS, VLBI, and SLR analysis programs. The following file types are
currently supported:
Runstring:
10 April 2015
5
The output binary h-files are named with the time and date of the mid-point of the
solution and a 4-character solution name, plus a 3-character extent that identifies the type
of input solution:
hyymmddhhmm_XXXX.[ext]
For GAMIT h-files, the solution name ( xxxx ) is the same as input h-file; for SINEX it is
first 3 characters plus the character before the last '.' in the name. GAMIT files have
extents which depend on the type of analysis—normally glr for biases-free or glx for
biases-fixed from the loosely constrained solutions. Extents for constrained solutions and
for h-files produced by GAMIT releases prior to 9.2 (Mar 92) are explained below.
To replace the a priori constraints in SINEX files the -C=<new constraint> option may
be used preceding the SINEX file name, where <new constraint> is the constraint in
meters (only station coordinates are allowed at present). If -C=0 is used the constraints
are left unchanged. This form may be used multiple times in the runstring and stays in
effect until changed; .e.g.,
replaces the constraints in the EMR files with 10 m, and the COD file with 0.1 m. For
some SINEX files there can be numerical problems if the new constraint is made too
large. Note also that constraints are changed only if they are smaller in the SINEX file.
If the outputs are required in the current directory then the directory name can be given as
'.' or './'. The / at the end of the directory name is optional. (It will added if it is
omitted.)
All of the binary files can be produced by htoglb in one run. If you have your directories
set up as indicated in Section II, then to create binary files, for example, for days 51–59
of 1993 you could type from your soln directory
where the first argument is the output directory, the second is the file for writing out
ephemeris and a priori coordinate information, and third is the input file(s). All of the
Unix wild cards work for the names of the files to be input to htoglb. The above case
would put the globk binary files in directory ../glbf, and the ephemeris and station-
coordinate information would be appended to ../tables/svs_myexp.svs, and the 'a' series
h-files in directories 051,052,...,059 would be converted. If you not wish to extract
ephemeris information—no longer needed by globk since the introduction of the
make_svs command—and you don't need to extract coordinates for new stations, you can
substitute /dev/null for the file name in the second argument. To see which files will be
used by htoglb, you can just use 'ls ../05[1-9]/h*a.05[1-9]'. It is not critical if a non-
h file is input to htoglb. The program can quickly detect if the file type is not correct
10 April 2015
6
Since GAMIT h-files can and usually do contain multiple solutions, globk files are
produced for each solution by changing extents. Although it’s possible to write into the
h-file both the constrained and loose solutions, the normal H-files will contain just the
bias-free and bias-fixed loose solutions. Htoglb will name the output binary h-files with
the date of the observations plus an extent identifying the solution, glr for the bias-free
soution and glx for the bias-fixed solution (e.g. h08110706a.glx for the bias-fixed
solution for 7 November 2008). If the ambiguities were reliably resolved then the glx
file should be used in globk.
Although the nrms scatter of the double difference residuals from the solve run is passed
in the h-file, this information is not used; that is, globk does not automatically scale the
covariance matrix from solve during the processing. It is possible, however, to explicitly
rescale the matrix by adding the scale factor to the input list of h-files as described in
Chapter 3.
Runstring:
% htoglb [dir] [ephmeris file] <input files ..... >
If the outputs are required in the current directory then the directory
name can be given as '.' or './'. The '/' at the end of the directory
name is optional. (It will be put there if it is not there.)
10 April 2015
7
htoglb output
As htoglb runs it produces summary information about the solutions it finds in the h-files.
This information includes the number of stations (and a list of these), the number of
satellites (and a list), and the number of parameters estimated. At the end of processing
each h-file, the number of solutions in the h-file is printed. The output from htoglb can be
re-directed to a file, and this file can be kept as a record of the processing of the data.
----------------------------------------------------------------
Processing file 1 h-file /data3/tah/gotexh/hgotxa.312.gm
There are 20 stations in /data3/tah/gotexh/hgotxa.312.gm
Name Full name
1 ARGE Buenos_Aires
2 AROG Algonquin_TI
...
20 YKNF YELLOWKNIFE
There are 7 satellites in /data3/tah/gotexh/hgotxa.312.gm
Name
1 PRN_06
2 PRN_09
3 PRN_11
4 PRN_13
5 PRN_12
6 PRN_03
7 PRN_08
Found 123 parmeters estimated in solution
There are 20 stations in /data3/tah/gotexh/hgotxa.312.gm
Name Full name
1 ARGE Buenos_Aires
2 AROG Algonquin_TI
...
20 YKNF YELLOWKNIFE
There are 7 satellites in /data3/tah/gotexh/hgotxa.312.gm
Name
1 PRN_06
2 PRN_09
3 PRN_11
4 PRN_13
5 PRN_12
6 PRN_03
7 PRN_08
Found 123 parmeters estimated in solution
2 Solutions extracted from /data3/tah/gotexh/hgotxa.312.gm
----------------------------------------------------------------
Processing file 2 h-file /data3/tah/gotexh/hgotxa.313.gm
There are 21 stations in /data3/tah/gotexh/hgotxa.313.gm
Name Full name
1 AROG Algonquin_TI
2 ARGE Buenos_Aires
...
21 YKNF YELLOWKNIFE
There are 7 satellites in /data3/tah/gotexh/hgotxa.313.gm
Name
1 PRN_06
2 PRN_09
3 PRN_11
4 PRN_13
5 PRN_12
6 PRN_03
7 PRN_08
10 April 2015
8
The output continues in this fashion until all of the input files have been processed.
The binary h-files produced to this point were
h88110706a.glb h88110706a.glc h88110806a.glb h88110806a.glc
The empheris file from htoglb looks like this. The example below is from one of the
TREX experiments. (The output has been modified slightly to fit on the page. Any line
with a non-blank character in column one is treated as a comment.)
10 April 2015
9
Htoglb generates only a few error messages. The most common of these is that it can't
find an h file (if the name is explicitly given, for example), or that a selected file is not a
h file (in this case the first line in the file did not match the expected pattern is printed).
This error may be generated if the version of GAMIT producing the h file is inconsistent
with the version of htoglb being used.
File errors generated by htoglb (and most of the other programs in the suite) are of the
form:
<Type> error <nnn> occurred <action>ing <file> in <module name>
2.2 apr_file
The file specified by the apr_file command for globk or glorg specifies the a priori
coordinates and velocities to be used for the sites in the solution and has the same form as
the Cartesian version of the GAMIT L-file. It is not necessary to include all of the sites
in the apr_file since globk can extract the a priori coordinates from the h-file. However,
a priori values are useful, and sometimes necessary whenever a site is renamed, has its
velocity linked to a nearby site, or is used in defining the reference frame. Precise values
for IGS/ITRF sites are provided in the apr files found in gg/tables or the /tables
10 April 2015
10
It is also possible to have non-secular terms for the apriori coordinates of the stations.
These terms are added using a additional lines in the apr-file, detected by EXTENDED being
the first token on the line. The additional terms can be periodic, exponential, or
logarithmic or changes in the postion and rate. The format of the new lines is as follows:
EXTENDED <Site Name> <Type> <YY MM DD HR MN> <Parameter> <Coefficients for NEU>
where EXTENDED should be preceeded by at least one blank. The line is not case
sensitive.
EXTENDED JPLM_GPS Periodic 2000 1 1 0 0 365.25 0.0 0.0 0.0 0.0 0.001 0.009
OFFSET Episodic change in position and velocity. Applied after <YY MM DD HR MN>
<Parameter> in this case is not used (value of 0.0 should be given).
The coefficients are paired as offset and rate changes applied after
the start date (i.e., offset + dtime*rate where dtime is time after
10 April 2015
11
EXTENDED JPLM_GPS Offset 1992 6 28 0 0 0.0 0.003 0.001 0.004 0.004 0.000 0.000
Each of the terms given should be unique. If duplicates (in terms of epoch, type and
parameter) are given, the last one read will be used. This extended model is meant for
use with time series analysis. The non-secular terms are not saved in any output binary
h-file. The position estimates and adjustment output by globk and glorg include these
terms evaluated at the epoch of the output solution. Finally, note that the EXTENDED
feature of the apr_file differs in the way it handles position changes from hfupd (Section
5.6) and the eq_file rename feature (Section 3.1). The eq_file rename changes the
"observed" station position in the input hfile whereas the EXTENDED feature in the
apr_file changes the "modeled" position. Thus, the signs are opposite to achieve the
same effect. To correct erroneous heights in h-files, hfupd is now the preferred means.
the EXTENDED offset feature in the apr_file should only be used with glred for
repeatability runs to account for coseismic offsets and rate changes, whereas the eq_file
feature and hfupd are used in globk runs when velocities are to be estimated.
10 April 2015
12
To run glred or globk you will need a file with a list of quasi-observation (binary h-) files
to process, a file of a priori coordinates and velocities for the stations, a table of Earth
orientation parameter values for the times of your data, and globk and glorg command
files. Conventionally the list files are given with a .gdl extent (global directory list) but
the name is arbitrary. For daily time-series analysis, the sh_glred script will generate a
gdl-file for each day automatically, but all other cases, when you are running glred
directory or globk, you will need to generate this list manually. The easiest method is to
use the ls command. For example, to generate a gdl-file for the biases-fixed h-files you
have created (with htoglb) for the 1996 Eastern Mediterranean survey, you might run
from the emed/1996/gsoln directory
% ls ../glbf/h*.glx > emed96.gdl
or, to create a gdl file from multiday combinations over several years, you might run
from the emed/vsoln directory
% ls ../????/gsoln/h*.GLX > emed.gdl
The gdl-file may optionally contain additional parameters following each h-file name to
indicate reweighting and coupling; e.g.
h9609061159_igs1.glx 1.0 +
h9609061159_igs2.glx 1.0 +
h9609061159_emed96.glx 4.0
where the numbers indicate the relative weighting of the estimates and covariance matrix
in the solution (e.g., the third h-file is to be downweighted by 4.0 in variance [a factor of
2 in uncertainty]); and the + specified for the first two files links all three together. There
is an optional additional value that can be included on each line to rescale the diagonals
terms of the covariance matrix. It is given in parts per million to be added to 1.0 and is
useful primarily for stabilizing SINEX files which have had their constraints removed.
An example of the use of this parameter is
h980126_stan.glx 4. 2 +
which would scale the covariance matrix by 4.0 and the diagonal elements additionally
by (1.0 + 2*1.d-6).
10 April 2015
13
(3) Specification of the uncertainties and the stochastic nature of the parameters in the
solution. These commands also determine which parameters are estimated, and how
the information in h-files is treated.
For commands of types (1) and (2), if a file or option is not mentioned, it will not be
used. Thus, for example, to invoke glorg from within globk, you must include org_cmd
with the name of the glorg command file; and to get a globk back solution, you must
include bak_file with the name of the back solution print file.
Commands of type (3) are more complicated since they depend on how the parameter
was treated in the analysis that produced the h-file and in some cases on combination of
parameters estimated. For parameters estimated in the previous analysis (i.e., present on
the h-file) entering a non-zero value in the apr_ command assigns an a priori standard
deviation of that value to the parameter. If the parameter has been constrained in the
previous solution, that constraint is not removed or altered, but rather the new value is
added to it. Thus, we recommend that you do not apply constraints any earlier than you
need to—only at the very last stage (glorg) for station coordinates and at the time of daily
combination for orbital and Earth orientation parameters. Markov commands (mar_) add
process noise with each new h-file, so that they have the effect of loosening the a priori
(apr_) value over time. Station coordinate and orbital parameters must be present on the
input h-file in order to be used in the solution or have constraints applied. For station
velocities, Earth orientation parameters (EOPs), and translation and rotation parameters,
however, globk can generate partial derivatives and add these to the solution even if they
were not on the h-file.
If a value of zero is entered for a parameter or if the parameter is not mentioned in the
command file (no apr_ command), the result depends on whether it was on the input h-
file and whether it is coupled to other parameters that are estimated. In most cases
(station parameters and velocities, orbital parameters) entering zero or omitting an entry
means to ignore the parameter and take no action. This means that if a parameter is
included in an input h-file and you don't mention it in the command file, it will implicitly
retain the constraints that it had originally while not being listed explicitly in the solution.
For example, if the h-file from the primary data analysis was created (e.g., by GAMIT)
with loose constraints on orbital parameters and you omit the apr_svs command, the
orbits remain implicitly loose in the globk solution; if the orbit was constrained in an
earlier solution, those constraints implicitly remain (through the station coordinates and
EOPs) even though the orbital parameters no longer appear in the solution. A special
case arises when estimating EOPs since they are directly coupled to station coordinates.
In this case, entering zero for any station coordinate will cause it to be fixed and used to
determine the EOPs.
In some cases, we want to explicitly fix a parameter without relying on the implicit rules
used in globk. In these cases, the letter F can be used for the apriori uncertainty of a
parameter. (Giving zero for the a priori sigma will not work because zero would generate
the same action, or lack thereof, as not saying anything about the parameter.) F for an
uncertainty will be interpreted as zero uncertainty in the apriori value of the parameter
10 April 2015
14
(i.e., fixed) but the parameter will be given parameter space and included in the output of
the program. (This latter feature is useful for keeping a record of the exact values of the
parameter used in the solution.)
In summary, the basic rules of globk’s interpreter are (consult the example command file
below for commands):
(1) The apriori values of parameters (station positions and velocities, and satellite orbit
information) are taken from the files given by the apr_file and the svs_file. If some
quantity does not appear in these files, then the apriori value will be the apriori value
from solve (post 3.2 versions of htoglb) or the estimate of the parameter from its last
occurrence in the input global files. (If the parameter was originally fixed in solve, then
this value will used.)
(2) If any parameter that does not explicitly depend on other parameters is given zero
uncertainty (either explicitly or by neglect), it will not be constrained at all, and it will not
appear in the output of the solution. (Use of the all option for station and satellite names
allows easy assignment of uncertainties to all parameters.)
(3) If any parameter that does explicitly depend on other parameters that are being
estimated, is given zero uncertainty (either explicitly or by neglect), it will be fixed to its
apriori value (independent of where this value comes from, see 1). Even though it is
fixed, its value will not appear in the output. If you want to explicitly control globk use
the F option for the uncertainty of a parameter you wish to fix.
If the three rules above are kept in mind, then it should not be difficult to get globk to
perform the solution you want. Since globk solutions usually take only a few minutes to
run for a typical GPS campaign, and less than half an hour for a complete sequence of
experiments, it is recommended that you play a little with the options and the implicit
rules just to be sure that you understand them.
Orbits are treated somewhat differently from other parameters in globk. The integration
epoch of the orbit (i.e., the epoch to which the orbital elements refer) is passed from arc
through the h-files to globk and globk keeps track of this quantity. While the IC epoch
remains the same, the stochastic parameters associated with the orbital arcs are used.
However, when the IC epoch changes, the uncertainties that were given for the apriori
values of the orbital elements are reimposed on the estimates, thus effectively breaking
the multiday orbital arc. Whenever, the IC epoch changes, globk prints a message to std
out and the globk log file saying that it is updating the IC epoch. These messages should
be checked when data are first processed to ensure that the correct multiday orbital arcs
are being used. (For example, an incorrect reference to a t-file could cause a break in the
middle of a multiday orbit arc.) The parameters representing satellite antenna offsets,
though associated with the orbital parameters, are not treated on an arc-by-basis, but
rather globally, so that that a single set of parameters is used for each satellite for a
solution.
10 April 2015
15
% GLOBK <std out> <print file> <log file> <experlist> <command file> <option>
where
<std out> is a numerical value (if 6 is typed then output will be sent to current window,
any other numerical value will send output to a file fort.nn)
<print file> is a numerical value or the name for the output print file with the solution
in it. If the print file already exists, then the solution will be appended to it unless
ERAS is specified for prt_opt. For output to your current window, 6 may be used.
<log file> is a numerical value for the log file that contains the running time for the
program and the prefit c2 per degree of freedom value for each input covariance
matrix file. If the log file already exists, then the new log will be appended to it.
For output to your current window, 6 may be used.
<exper list> is a list of binary h-files to process. Any file name may be used but
convention is to end it with .gdl.
<command file> is a list of commands controlling the solution.
<option> designates a string that may begin in the first column for a subset of
commands in the the command-file indicating that this command is to be used in
the run (and would be ignored if the command-line string doesn’t match the string
in the command file.
The next two sections describe in detail the commands of the globk/glred and glorg
command files. Following these, in Section 3.3, we describe in both theoretical and
practical terms the various approaches you might take to defining a reference frame for
GNSS data analysis. Section 3.4 gives examples for analyzing daily solutions to obtain a
time series for error analysis and for combining multi-year solutions to obtain a time
series or velocities. The last two sections of this chapter give examples of glred/globk
and glorg outputs and error messages.
*********************************************
* Annotated example of a GLOBK command file *
* (used for the analysis of GPS Data). *
*********************************************
*
* General rules:
* ------------------
* (1) All commands start with a blank in column one except when the
* ‘option’ feature is invoked. All other lines,including blank
* lines are considered comments and are ignored. This rule also
* applies to apriori station (except for EXTENDED entries) and
* satellite position files. Comments may also be added at the end
* of any command line by using the ! or # character as a delimiter.
* (2) Only the minimum redundant set of characters for commands, site
* names or satellite names are needed. For example, if only 4 characters
* of a site name are given, all 8-character versions of the site
10 April 2015
16
* These files do not need to exist before hand, they are simply used to * save
intermediate results. The com_file is used to store information
* that is needed to rerun the output program glout and the reference-
* frame-fixing program glorg If you are not calling glorg from within
* glred in performing daily solutions, you can save time by omitting
* the com_file command and hence not writing out the solution. (Program
* globk currently writes the com_file automatically whether you specify
* a name or not, but this will be changed in the future.) Note that the
* com file is not backward compatible between versions of the software.
* If you want the data processed in reverse time order, then uncomment
* the line below. If this is done the station coordinates, Earth
* rotation parameters, and satellite orbit parameter will refer to the
* first epoch of data and not the last as it does in the default case
10 April 2015
17
# srt_dir -1
*
* The preferred method for generating the a priori values of satellite
* parameters now is to read them from the input binary h-files and write
* them to a file specified at the top of the command file:
make_svs svs.apr [ Z ]
* When h-files from the same day are combined, the elements from
* the first hfile read will used. If the svs file already exists, it
* will be overwritten. If the make_svs command is missing, globk will
* look for the svs_file command which was formerly used to specify a
* list of apriori* satellite parameters written by htoglb or unify_svs:
* apr_svs <filename>
* If the optional Z is specified after the file name then the radiation
* parameters are set such that the direct radiation is 1.0 and all
* the other radiation pressure parameters are zero. This option is
* useful for stabilizing orbital solutions but can have adverse
* consequences if you tightly constrain a parameter that has been
* correctly adjusted to a non-zero value. When the rad_rese command is
* used, it is recommended that the Z-option be invoked. The default is
* not to invoke it.
eq_file landers.eq
* Now start the commands which do not depend on order. (When the first
* of these commands is issued, the program will first read all of the
* input global files and build up the list of stations and satellites to
* be used in the analysis.
* One more scratch file is needed. This file contains the covariance
* matrix for the solution, and if a back solution is to be run then
* contains the covariance of each global file in the solution. (In
* this latter case the file can get very large. Generally it is less
* than 1 Mbyte per global file, but for VLBI with over 1000 experiments
* is over a Gbyte.)
sol_file glbsol.bin
* You can have glred or globk automatically exclude from its solution
* h-files that contain corrupted data or a station for which you have
* no reasonable a priori coordinates using the command
10 April 2015
18
<max rotation> sets the tolerance for a rotation of the prefit station
coordinates before they are compared with the current solution. This
check complements the new feature of globk in which an orientation
difference between the stations of the input h-file and the current is
computed. If this value exceeds <max rotation>, then the rotation is
removed from the station coordinates and added to the EOP parameter
estimates and a message is written to the screen. The purpose of this
feature is to avoid having to set the Markov values of the EOP
parameters inordinately large to handle a few h-files for which the EOPs
of the phase processing had large errors. For global networks, the
rotation can be determined well from data, so setting a small
<max rotation> value (e.g. 20 mas) is useful to maintain small Markov
values. For regional networks, the rotation is poorly determined, so
the tolerance should be kept large to avoid erroneous rotations that can
cause numerical problems. The default is 10,000 mas.
10 April 2015
19
apr_file grece.apr
bak_file grece_fxd.bak
descript Test run of network with orbits and station DDDD fixed.
10 April 2015
20
# comp_res yes
* The form bak_file @.bak may also be used for the file name in which
* case the @ is replaced by corresponding characters from the experiment
* list file. i.e., for the case above, if grece_fxd.gdl was the
* experiment list, the bak file name would be grece_fxd.bak.
*
* Print commands
* ==============
*
* The output from globk is normally produced twice, once to your screen
* and once to your print (prt) file specified in the runstring. If a
* back solution has been commanded by specifying a bak_file, then a
* second file output is produced. The quantities to be written to the
* two files and the screen are specified separately with the prt_opt,
* bak_opt, and crt_opt commands, respectively. The specification is
* made with either a 4-character keyword or a binary-coded (bit mapped)
* integer value. The keywords, corresponding bits, and their meanings are
* as follows:
*
* CODE BIT Decimal
Meaning
* ---- --- -------
--------
* CORR 0 1 Output correlation matrix
* BLEN 1 2 Output baseline lengths and components
* BRAT 2 4 Output baseline lengths and components rates
* of change.
* CMDS 3 8 Write a summary of the globk command file to the
* globk and glorg output files.
* VSUM 4 16 Write the short version of the velocity field
* information (one line per station)
* 5-9 32-512 NO LONGER USED (see POS_ORG and RATE_ORG below.
* RAFX 10 1024 Fix the Right ascension origin of the system.
* MOUT 11 2048 Only output baselines if both stations are Markov.
* (Used to limit output in large back solutions)
* COVA 12 4096 Output full precision covariance matrix.
* PSUM 13 8192 Output position adjustments in summary form
* GDLF 14 16384 Output the contents of the GDL files used
* DBUG 15 Output matrix details when there are negative
* variances and negative chi**2 increments
* ERAS 16 Erase the output file before writing solution
* NOPR 17 Do not output the file (either crt, prt or org
* depending on opt set).
* SDET 18 Output details of the stabilization calculations in glorg
* RNRP 19 Report the statistics of the differences in positions and
* velocities of renamed sites. Also generates equate lines
* that can be filtered with shell script sh_exeqs. The
* equate lines are written to file <org root>.eqs
* FIXA 20 Automatically fixes differences in aprioris when equates
* are made (except for positions that differ by more than 1 m)
* PLST 21 Report the list of parameters to be estimated to the log
* file before running the globk filter. (If list is not the
* expected groups of stations, the globk run can killed, the
* globk command file fixed and the run re-started.
* GEOD 24 Output GEOD coordinates (WGS84) (sh_exglk -g option)
* UTM 25 Output UTM coordinates (WGS84) (sh_exglk -u option)
10 April 2015
21
* For example,to write to the print file baseline lengths, baseline rates,
* and a summary velocity field, set
10 April 2015
22
* ==========================
*
* The OUT_GLB command allows a binary h-file to be generated with globk.
* Thisfeature is typically used to combine all the data collected in a
* single experiment into a single h-file for later processing
*
out_glb [email protected]
*
* where @ takes in the characters from the experiment list file, .e.g.
* if the experiment list was exp_June92.gdl then the output global file
* would be com_June92.GLX. If glred is used to invoke globk, for example
* when combining a specified set of h-files using the + feature, the name
* of the out_glb file can be set to the date (YYMMDD) using
out_glb H------_expt.GLX
* If you forget to set out_glb in your globk run, you can create an output
* binary h-file from the globk com_file using the program glsave
*
* Selecting stations
* ==================
*
* A station may be excluded from the analysis by name, geographical
* region, or the number of times it appears in the input h-files. The
* default is to include all stations that appear in the h-files. To
* select by name, use the USE_SITE command, either starting with CLEAR
* to exclude all, and then adding the names of those you wish to include,
* or starting with ALL (default) and subtracting those you wish to
* exclude:
*
* use_site clear
* use_site sit4 sit5 sit6 ...etc.
*
* or
*
* use_site -sit1 -sit2 -sit3
*
* If a 4-character name is used all renamed vesions of this site will be
* selected; to select only some versions, use the full 8-character name.
*
* To select by region, use the USE_POS command to define a box
* within which you want to include or exclude stations:
*
* use_pos < +/- > <Lat LL> <Long LL> <Lat UR> <Long UR>
*
* where + indicates inclusion and - exclusion of stations within
* the box defined by the latitude and longitude (postive east) of
* its lower-left (LL), and upper-right (UR) corners. Thus the command
*
* use_pos - 30.0 -125 35.0 -115.
*
* specifies exclusion of stations between 30 and 35 degrees north
* and 115 and 125 degrees west (i.e., southern California). This
* command is used in conjunction with use_site. If use_site clear
* is initially specified, the use_pos + can add stations within a
* defined region; conversely, is use_site all is initially specified,
10 April 2015
23
*
* Selecting and constraining parameters to be estimated
* =====================================================
*
* For each type of parameter in the solution there are commands
* to specify the a priori sigmas. Since a Kalman filter requires
* some level of a priori constraint, if these commands are omitted
* for a particular group of parameters, these parameters will be
* ignored in the the input binary h-files. This is equivalent to
* allowing the parameter to freely vary between sessions of the data.
*
* You can also allow parameters to vary stochastically between
* observations (i.e., h-files) by specifying Markov process noise to
* be added. Specifically, the variations are modeled as random walks
* with a specified power spectral density (PSD) of the white noise
* noise process driving the random walk. Since the variance of the
* difference between two values in a random walk is given by PSD*dT
* where dT is the time difference in the units of the PSD time argument,
* you can easily compute how a given value will affect the solution.
* For example, a PSD value of 36500 m**2/yr for station coordinates
* will constrain the station position to +-10 meters (one sigma) between
* sessions separated by a day. Specifying stochastic variation of
* of parameters is an effective way of absorbing errors due to
* unmodeled behavior, such as the effects of non-gravitational forces
* on satellites, errors in a priori Earth-rotation information, post-
* seismic motion of stations. It is also a useful way of handling
* apparent changes in station position due to changes in instrumentation
* or blunders in measuring antenna heights. Finally, allowing
* stochastic variation of station coordinates and running a Kalman back
* solution may be used to test the repeatability of the values in a set
* of data, though for most data sets this can be done more efficiently
* by treating each day (h-file) independently and ruuning glred instead
* of globk (see section III.d below).
10 April 2015
24
apr_site dddd F F F 0 0 0
* Both the H-file name and time span entries are optional. There is
* a 1-minute (inclusive) tolerance on the time entires. You can apply
* noise to a group of renamed stations using @[string];* e.g., @_BAD
* would match all stations renamed to end in _BAD.
* All entries which apply to a station are used (in a variance sum)>
10 April 2015
25
* would set direct and y-bias sigmas at 100%, and the b-axis and once-
* per-rev sigmas at 2%. The values for the unused z-axis and x-axis
* parameters are set here to zero but would be ignored by globk
* since they do not appear in the binary h-files. If differeent
* sets of parameters are used in different solutions, you should set
* realistic sigmas for all 14 parameters. The non-gravitational
* parameter sigmas can also be added to the apr_svs command line
* (after the 6 for position and velocity of the satellite).
* The third set of satellite parameters are for SV antenna offsets and
* have units of meters.
10 April 2015
26
* where <file
name> is the name of a file containing new Markov
* information
satellites (will be used instead of the values given in
* the mar_svs
command.) The format of the file is:
* YY MM DD HR
Dur PRN Mar X Y Z Mar Xdot Ydot Zdot Mar SRP Y- Z-bias
* (days) (units as above)
90 10 12 6 2.5 PRN_12 36500 36500 36500 365 365 365 365 0 0
* where Dur is the duration in days over which this alternative set of
* markov parameters should apply. As many as entries as desired can be
* put into the file.
rad_reset no
10 April 2015
27
* first h-file read in, and the adjustments will be the average from
* this value.
*
* The val_svan comman allows you to change the a priori values of the
* antenna offsets:
* where <x>, <y>, <z> are the new offsets in meters. If DEF is used
* for a numeric value, then the default value (i.e., the value used in
* GAMIT will be retained; e.g., val_svan prn_13 def def 2.0 would
* change just the Z component to 2 meters.
* The entries for pole (wob) are x and y, x-dot and y-dot, and for
* axial rotation, UT1 and its rate. Both pole and UT1 have units of
* milli-arcseconds (mas) and mas/day. The need for pole position
* estimates is dictated by how well you know the positions of any
* heavily constrained stations coordinate system defined by the
* a priori Earth rotation tables. Also note that if all orbital elements
* are estimated, then UT1 can be arbitrarily given zero apriori sigma,
* since any UT1 error will be absorbed in the longitudes of the nodes of
* the satellite orbits (though we normally put a non-zero value in order
* to monitor rotations of the orbits).
*
* The units of random-walk variations of Earth rotation parameters are
* mas**2/yr for offsets and (mas/day)**2/yr for rates. The example
* below allows +-1 mas between sessions separated by one day.
* The need for these parameters is determined by how well you think
* your apriori Earth rotation series remains fixed to your system
* of coordinates. The Markov constraints are implemented in such a way
* that the coupling between angles and rates is accounted for; that is
* the constraint applied to rates as a random walk (RW) becomes an
* integrated random walk (IRW) constraint on angles, applied in addition
* to the explicit random walk constraint applied for the angles
* themselves. See the discussion in Herring et al. [1990]. Note that
* in version 5.02 the formulation of the IRW was changed from one used
* in earlier versions, which seemed to couple angles and their rates
* too strongly, to one that is more statistically correct (and closer to
* the one described in Herring et al. [1990]). If you wish to retain
* temporarily, for consistency, the more strongly coupled model, you can
* use the command 'irw_mod old' .
* For global analyses in which you want to extract pole and UT1
10 April 2015
28
apr_rot <xig X> <sig Y> <sig Z> <sig Xrate> <sig Yrate> <sig Zrate>
* where the first three entries are for rotations about the X, Y, and Z * axes
in units of mas, and the second three for rate rates in mas/yr.
mar_rot <RW X> <RW Y> <RW Z> <IRW X> <IRW Y> <IRW Z> <WN X> <WN Y> <WN Z>
* where the first three entries are for the random walk process in units
* of mas**2/yr, the second three for an integrated random walk process
* in units of (mas/yr)**2/yr, and the last three for a white noise
* process in units of mas**2. The white noise values, not available
* with the mar_wob and mar_ut1 commands, allows you to specify a process
* for which the noise level is not dependent on the spacing of the
* observations.
* where the first three values are the sigmas in x, y, and z, and the
* last three sigmas of their rates in units of meters and meter/yr or
* for Markov m**2/yr.
10 April 2015
29
apr_scale 1. 1..
mar_scale 365 0
* where the units are parts per billion (ppb), ppb/yr, and ppb**2/yr.
* Correcting models
* ------------------
*
* In principle a number of effects included or omitted in the original
* processing can be corrected at the globk stage, provided their signature
* can be modeled by changes in the quasi-observations. The two examples
* currently implemented are the pole tide and (non-tidal) atmospheric
* loading.
* To apply the pole tide in globk or correct a model that may have been
* applied by an older version of GAMIT, use command
* where < list of h-file codes > is a list of strings that should appear
* in the h-file name for any data to which you wish the pole tide
* applied. For GAMIT-produced h-files, you may safely include this
* command all the time since globk will detect from the headers the
* model applied in the phase processing and apply the appropriate correction.
* app_atm
*
* Another "model" change that can be made is a station's antenna offset
* from the monument. This change, accomlished along with corrections
* to other receiver and antenna information, is performed by utility
* hfupd by reading station.info (see Section 5.10).
* This command defines the earthquake. <Code> is a two letter code which
* is used (optionally) in renaming sites and identifying this earthquake
* in subsequent commands. The code cannot be the same as the last two
* (7th and 8th) letters of any station affected by the earthquake.
* Specifically PS can never be used as a code since _GPS forms the last
10 April 2015
30
eq_renam <Code>
* This command tells globk to rename the stations affected by the earth-
* quake by replacing the last two letters of the station name by the
* code for the Earthquake. This command can be used in conjunction with
* the stochastic options discussed below. For generating apriori
* coordinate files, this is the preferred option. If no apriori
* coordinate and velocity is in the apr_file for globk for the renamed
* station, the values for the original station will be used.
10 April 2015
31
eq_pre <Code> <dur> <Static Markov NEU> <Spatially dependent Markov NEU>
eq_post <Code> <dur> <Static Markov NEU> <Spatially dependent Markov NEU>
eq_log <Code> <tau (days)> <static NEU sigma (m)> <spatial sigma NEU>
* These command, which also goes in the *earthquake file*, NOT the globk
* command file, rename stations in the solution to account for discontinuties,
* distinguish duplicative 4-character site names (e.g. from different
* institutions, or to exclude data. With the break command, globk will assign
* the new 4-character extent, taking in to account earthquakes and replacing
* the 6th character (usually “G”) with “1”, “2”, etc. Renaming a station
10 April 2015
32
* to end in _XPS will cause it to be removed from any velocity solution but
* retain it in time series; _XCL will cause it to be removed from both.
* <Orig Site name>is the site name that appears in the binary h-files;
* and <New site name> is the name you wish to use in the current
* solution. It should not conflict other names in the binary h-files.
* The following arguments are optional:
* [hfile code] is a string that must appear in the name of
* the h-file for the rename to be applied. This argument may be omitted
* since globk can distinguish whether the third argument is a string or
* a number (epoch range); however, you cannot use a string that is
* entirely numerical. <epoch range> is range of time over which the
* rename will be applied, specified as a pair of year month day hour min
* values (all separated by spaces). Any hfile in which the start date
* is after the first date and the end date in before the second date
* given will have the station renamed. <Position change> is the change
* in position to accompany the name change. It is given in either XYZ
* or NEU (three values) followed by a type declaration (XYZ or NEU). If
* no type is given, XYZ is assumed. Units are meters and the change
* should movethe station from the original position to the new position.
* North, East and Up (NEU) are defined as North along (the ellipsoidal)
* meridian direction at the apriori coordinate of the new site name,
* East along the East longitude direction, and ellipsoidal height. The
* rotation matrix is defined by these directions and the NEU are rotated
* to XYZ using this rotation matrix. NOTE: The renames are applied
* before any earthquake processing, so names generated from earthquakes
* use the new station name.
*----------------------------------------------------------------------
* Example of eq_file entries
10 April 2015
33
*
* Running glorg from within globk or glorg
* =========================================
*
* Although running glorg separately from globk can be useful
* and efficient in refining the analysis, it is more convenient
* in the intial velocity solution—and essential in time series
* analysis, to invoke glorg from within globk. This is accomplished
* with the command
* where <glorg command file name> is the name of the command file with
* the glorg commands in it (see section III.f or online glorg.hlp).
* This command is usually accompanied by
* where <File name> is the name of the output file. If this is not
* given then the output goes to file name generated by replacing the
* characters after the last period (.) in the print file name with
* 'org'. If there is no last period, then.org is appended.
10 April 2015
34
Glorg is the origin (translation and rotation) fixing program for the data analysis. It
allows the reference frame of the solution to be specified after all of the data have been
combined by globk (with loose constraints). Thus, many realizations of the frame may
be tested quickly by fixing different combinations of coordinates and velocities.
Translation, rotation, and scale may be estimated by a minimization of the deviations
between horizontal positions and velocities given in the apriori station position file.
Glorg also allows you impose other constraints such as forcing the velocity adjustments
of nearby stations to be equal. The chi-square increment from each constraint is shown in
the output file so that you may evaluate its affect on the solution. The apr_file used for
glorg need not be the one used for globk. (In this way, for example, you could run globk
with velocities which represent your best estimates, but then display differences to a
standard plate motion model.) Glorg may be invoked from within globk/glred, as is
typically done to generate daily solutions to examine repeatability, or executed as a
separate program following combination of data from many days or years. Examples of
each of these applications are given in Section 3.4.
The run-string and commands used are documented below. A current version of this
documentation may be found in the on-line help for glorg.
GLORG: Origin resolution program for the GLOBK.
Runstring:
where <output> is the name of the output file (may be 6 for output
to current window.
<options> are the print options for the output file, specified by
the same 4-character codes as for globk except that there are
additional options specific to glorg:
SDET : output the details of the stabilization calculations
FIXA : automatically fix differences in a priori positions or
velocities
RNRP : report statistics of the differences In the positions
and velocities of renamed sites; also generates equate lines
that can be filtered with script sh_exeps.
If glorg is invoked from within globk, the options are given by the
org_opt command in the globk command file. If glorg is run alone,
they must appear in the command line separated by colons or equal signs;
e.g. glorg test.org blen:psum glorg.cmd test.com
APR_FILE Gives the name of the new apriori position and velocity file.
10 April 2015
35
The command may be issued multiple times, with the last values
read for a station taking precedence
equate n1 n2 n3 n4
constrai <sigma> n1 n2 ..
.
where sigma is in units of the parameters.
10 April 2015
36
LOCAL_EQ Used in conjunction with EQUATE and FORCE. The default is now
to apply these constraints in local (NEU) coordinates, but
XYZ may be used by setting LOCAL_EQ N. Command may be issued
only once and applies to all forces and equates.
CND_HGTV Used to determine from the height sigmas which of the stations
in the stab_site list are retained defining the reference frame.
Four values are given. The first two are the variance factors
applied to heights and height rates relative to the horizontal
components in estimating the origin position and velocity. The
second two set limits on the sigmas of the height and height rates
of station to be used. They are meant to exclude stations with
10 April 2015
37
STAB_MIN Allows the user to set the minimum values for the cnd_hgtv
limits on heights sigmas of sites to be used in the stabilization,
and on the minimum RMS to be used in postfit rms editing.
The command format is:
stab_min [dHsig min pos] [Min RMS pos] [dHsig min rates] [Min RMS rate]
10 April 2015
38
where <plate name> is the name of the plate. The rotation vector
is given in the glorg print (.org) file. If more than one plate is
defined, the the relative rotation vectors (Euler poles) are also
given. A station should not be specified on more than one plate,
nor should two 8-character versions of the same station (e.g.
ALGO_GPS, ALGO_1PS) be used if their velocities have been equated.
When the plate command is used, the horizontal adjusments (but not
the values) of velocities in the org file are replaced by the residuals
with respect to the plate with which it has been associated. A cleaner
way to see the plate residuals is to run sh_org2vel to generate velocities
of all stations with respect to the plate given in the command line.
10 April 2015
39
For global- or continental-scale networks, you may (and usually should) estimate
translation and rotation (scale is not so clear---see Dong et al. [1998]) and include as
reference (“stablization”) sites a distributed set of stations (at least 10, preferably more)
for which you have both good a priori values and good data. In this case both site
coordinates and EOPs should be left free in the globk command file:
apr_neu all 1 1 1 .1 .1 .1
apr_wob 100 100 10 10
apr_ut1 100 10
mar_wob 36500 36500 365 365
mar_ut1 36500 365
(In a glred solution for a single epoch, you would set the velocity entries to zero in the
apr_ commands, omit both the mar_ commands, and rate_org.) would be omitted in a
glred solution for a single epoch as would the mar_ commands.) For a global analysis
orbital parameters would usually be kept free
whereas for a continental-scale analysis they might be constrained or fixed if the GAMIT
processing used sufficiently accurate orbits:
For a local or regional analysis in which you do not have a large number of well-
distributed reference stations, you may be able to estimate robustly in glorg only a
translation of the network. In this case you must constrain the rotation in globk:
These values are realistic for IERS rapid or final values and limit rotations to 0.25 mas
and 0.1 mas/day, equivalent to 0.3 mm, 0.1 mm/day over a 2000-km baselne.
The reference frame for you solution is realized by data you have for the sites specified in
the stabilization list (stab_site) and the a priori coordinates you specify (apr_file in
glorg). In realizing the frame, glorg performs an iterative procdure to determine the
whether the data from stabilization sites are consistent with the coordinates of the apr-
10 April 2015
40
file. This procedure is described and illustrated with an example in Section 3.5 If you
have defined one or more stable blocks for with respect to which you want to view the
velocities (plate command) glorg will follow the stabilization with estimation of rotation
vectors (Euler poles) for these blocks, which you can use (sh_org2vel) to obtain the
velocities of the sites with respect to each block.
The first step in GPS post-processing is usually to generate a time series of station
coordinates using glred to identify and remove any surveys or stations which are outliers.
For a global analysis, the reference frame may be constrained on each day using in glorg
a stabilization list that includes a reliable set of IGS stations. For a regional analysis in
which you include in globk only a few IGS stations, obtaining the best time series usually
requires an interative process. First you generate time series (with glred ) using the IGS
stations to define the frame. Then remove obvious outliers and perform a combined
(globk) solution to obtain a consistent set of coordinates for all of the stations. Finally,
run glred again, this time using all of the stations in the glorg stabilization. This
procedure effectively defines a regional frame of reference, allowing you to remove
common-mode errors without choosing a single reference station.
For an analysis using both global and regional data the .gdl file will have the form
h9609061159_igs1.glr 1.0 +
h9609061159_igs2.glr 1.0 +
h9609061159_emed96.glx 1.0
h9609071159_igs1.glr 1.0 +
h9609071159_igs2.glr 1.0 +
h9609071159_emed96.glx 1.0
...
(or with the 1.0 scale-factors omitted) where the h-file names for each day indicate the
two global subnetworks analyzed by SOPAC and an h-file from an analysis of regional
data from the 1996 Eastern Mediterranean survey. Glred treats each input h-file
independently, but adding the + symbol to the first two of each triplet of h-files for each
day forces the parameters to be the same for the three solutions, thus tying together the
orbital and Earth orientation parameters, as well as any common stations, from the global
and regional solutions. The number following the h-file name is a variance factor
(relative weight) for the file.
10 April 2015
41
Execution of glred with this command file will generate a loose solution, recorded in
emed96.prt, and will invoke glorg to generate a constrained solution, recorded in
emed96.org. The glorg command file (glorg.cmd) will look something like the following:
10 April 2015
42
In the glorg command file, we have specified that the reference frame is to be defined by
minimizing the position deviations of 11 IGS core stations (Hartebeesthoek and Santiago
are omitted because of poor data during this period) while estimating a translation and
orientation.
If you have a small regional network and want to maintain the orientation of the reference
frame through the IGS orbit and IERS Earth orientation values, without introducing
global h-files or tracking data, the bottom of the glred command file would look like the
following:
and the glorg stab_site command for the initial run might contain only 3–6 stations
whose coordinates are well known a priori. If there are only a few stabilization stations,
and/or the spatial scale of the network is small, then you should estimate only translation
parameters in glorg:
After running glred, you can plot the time series using the scripts described at the end of
this section. Then you would remove problematic data, either by renaming the station for
a particular span (e.g., rename SSSS_GPS SSSS_XCL in the eq_rename file) or commenting
out (with #) the h-file in the gdl file. In the case of a regional analysis (with or without
the inclusion of the global h-files), the next step is to run globk to obtain a self-consistent
set of coordinates for all the stations. For this run, use the same command file as for the
initial glred run, except that you need to allow for time-changes in the EOP values :
If time span is longer than a single survey, you may also need to estimate a velocity for
each of the stations:
apr_neu all 20 20 20 1 1 1
After inspecting the globk run for consistency (chi-square values in the log file and rms
of the glorg stabilization), you should now extract the coordinates for a new apr file from
10 April 2015
43
the glorg print file using grep 'Unc.' as described in Section 2.2. This new apr file will
become the sole reference in glorg for the glred runs to generate the final time series (it
doesn't matter what apr file you use in the glred command file). For this run, the glred
command file will be the same as before, but the glorg command file will look like the
following:
To plot coordinate repeatabilities from your glred solutions for a single survey using
GMT, execute
sh_plot_pos –f globk_rep.org
This script invokes tssum to scan the solution file (globk_rep.org) for the north, east, and
up coordinates in PBO format estimated for each day and generate PBO-style pos files,
which will then be used with GMT to produce time series for each of the stations and a
pair of histograms showing the distribution of weighted and normalized rms
repeatabilities. If the data extend over several years, then you should specify the start
and stop tims using –t1 and –t2 and have a trend removed by specifying –o 1. See the
sh_plot_pos help for the full list of options. An alternative plotting scheme, which will
be phased out after 2015, is to use script sh_plotcrd to invoke ensum and multibase to
produce mb_ files for plotting by GMT. Since either script will create a large number of
files (one per station), you may want to have these put into a separate directory (e.g.
gsoln/plots). With sh_plot_pos, this can be done automatically with the –d option; with
sh_plotcrd, you would create the /plots directory manually and then execute the script from
that directory (e.g., -f ../soln/globk_rep.org.)
Multi-year solutions are best accomplished by first combining the h-files from individual
sessions into a single h-file. This is not only more efficient in terms of processing time
and disk storage, but allows you to generate statistics for long-term repeatability without
mixing in the short-term scatter. To combine the data from a single survey, run globk
using the command file described in the last section but add a line specifying the output
file name:
out_glb EMED96.GLX
10 April 2015
44
The uppercase file name is not required but is a useful convention to denote a combined
h-file. Optionally, at this point you can perform a second globk run in which you use the
output h-file (EMED96.GLX) as sole input in the .gdl list, specify a new output
out_glb EMED96.GLN
and suppress the orbital parameters by commenting out the apr_svs line. Since the
orbital information has now been incorporated into the estimates and covariances of the
station coordinates, there is no reason to carry them forward to the multi-year solution.
On the other hand, they do no harm beyond the additional disk space needed to store
them, so you may want to skip this step, at least until you are sure that the combined h-
file is the one that you wish to store for future use. (Future versions of globk may allow
use and then suppression of orbital parameters in a single run, thereby avoiding this
additional step.)
To obtain a multi-year solution, your .gdl file will contain only the combined files from
each survey:
EMED96.GLX
EMED97.GLX
EMED98.GLX
...
To get velocities, run globk with the same command file except the apr_neu line now
specifies that velocities as well as positions are to be estimated
apr_neu all 20 20 20 1 1 1
Earth orientation and the reference frame can be specified in the same way except that
you must now constrain velocities as well as position. In the globk command file set
org_opt BRAT CMDS PSUM VSUM
The BRAT print option for glorg is necessary if you want to see directly the values and
uncertainties of relative velocities between the stations in your network. For large
networks this can increase the size of the print (.org) file considerably, so if geocentric
velocities are well determined, as is often the case with global analyses within the last
few years, or if you have performed a regional stabilization, you may want to omit BRAT
from the print options.
In the glorg command file you now need to specify parameters for both position and
velocity stabilization:
pos_org xrot yrot zrot xtran ytran ztran
rate_org xrot yrot zrot xtran ytran ztran
10 April 2015
45
where maxsigma gives maximum uncertainty in millimeters of sites to plot. Chapter 4 and
the on-line help describe additional options for sh_plotvel that will allow you to produce
journal-quality velocity maps including topography, tectonic features, and customized
labels.
There are a variety of reasons why you may want to treat station coordinates, orbital
parameters, and Earth orientation parameters stochastically in your globk analysis. The
classic method for analyzing the day-to-day or year-to-year variability of station
coordinates or baseline components is to treat a subset of them stochastically and run
both a forward and backward Kalman filter with the data. By performing both the
forward and back solution, you obtain the best estimates of the coordinates and velocities
of the stations treated deterministically at the same time as obtaining the variability of the
stations treated stochastically. This approach has several disadvantages, however. The
most obvious is the difficulty of deciding which stations to make deterministic and which
to make stochastic. To retain nearly the full strength of the velocity solution, you would
want to make only a few stations stochastic at a time, requiring many runs to see all of
the repeatabilities. On the other hand, making deterministic a station for which there are
outliers corrupts the solution and the apparent repeatability of other stations. A better
approach to determining repeatabilities is to use glred to estimate all coordinates
independently for each session or survey, with the reference frame maintained by glorg
stabilization with as many stations as possible, as discussed in the previous section. With
this approach the network can translate and rotate from solution to solution, but any
internal distortions represent real problems with the stations exhibiting them.
A more common current use of stochastic station coordinates is to account for time-
correlated sources of error in the estimates of station position, including monument
instability and signatures in global time series that may be due to errors in modeling the
orbits or atmosphere. For example, to include random-walk noise at the level of 2 mm⎟yr
in the horizontal coordinates, the globk command file entry would be
Prior to globk 5.05, Markov noise was also used to decouple erratic fluctuations in the
estimates of vertical coordinates due to tropospheric noise, antenna changes, or blunders
in entering the height of the antenna. The time-dependent nature of Markov noise makes
it a poor proxy for these fluctuations, however. A better approach is to add random noise
to the height estimates via the (new) neu_sig command. For example, to allow for 10 cm
fluctuations in the vertical component for Kokee Park, the entry would be
(If there are identifiable steps in the estimate of heights, you should rename the station at
the time of the step [e.g., rename KOKB_GPS KOKB_APS] then equate the horizontal but not
the vertical coordinate adjustments in glorg.)
10 April 2015
46
UT1 and pole position are defined as single (global) parameters in globk, so to allow day-
to-day variation you must specify for them a Markov process. The level of constraint
depends on the precision and stability of your a priori Earth rotation series as described in
Section 3.3.
For orbital parameters, stochastic variations are used in conjunction with multi-day arcs,
most valuable prior to 1994 when the global tracking network was not strong enough to
produce few part-per-billion orbital accuracy from a single day's observations. There is
considerable flexibility in globk's use of stochastic parameters for orbits, allowing
different levels of Markov constraint for each element of each satellite for each survey
period. The difficulty, however, is determining in an efficient and objective manner what
level to use. The analyst is forced to experiment with different values, using the chi-
square increments between days from a globk non-stochastic forward solution and the
day-to-day variations of the parameter estimates from a glred or back solution as a guide
to choosing the optimal values. As a starting point, we discuss three levels, which we
will designate "loose", "moderate", and "tight" orbital Markov constraints.
"Loose" constraints would allow about 10 m/day (36500 m2/yr) variation in satellite
initial position and 1 mm/s/day ( 365 (mm/s)2/yr) variation in initial velocity, and 2–100
%/day (0.15–365 /yr) variation in non-gravitational ("radiation-pressure") parameters:
mar_svs all 36500 36500 36500 365 365 365
mar_rad all 365 365 .15 .15 .15 .15 .15 .15 .15
Remember that "loose" is defined with respect to the uncertainties you would obtain with
a single-day's data with your actual data set, so these values can only be considered a
guide. More study is needed to determine the relative weighting of initial conditions and
non-gravitational-acceleration parameters to absorb a given degree of mis-modeling of
the satellites' motion. In the example shown, we have allowed a relatively large "reset"
of initial conditions each day, a large adjustment of the direct-radiation and y-bias
parameters, and only a small (2%) change in the other non-gravitational acceleration
parameters (the constant along the "B" axis and the once-per-rev coefficients in the Berne
model; see Section 7.2 of the GAMIT manual). An alternate strategy would be to keep
the initial condition variations small but allow large variations in all of the non-
gravitational acceleration parameters. Values of the Markov constraints much looser than
the ones shown here would completely decouple the orbits from day to day, effectively
estimating the orbital motion in single-day arcs even though you have formally used a
multi-day T-file with a single set of initial conditions. With loose Markov parameters for
the orbits, if you are combining more than one h-file for each day (e.g., with regional and
global observations), it is essential in this case to have the centers of the h-file data spans
(the center of the X-file) match. Otherwise, you will decouple the orbital parameters
estimated from the two h-files.
An example of "moderate" constraints would allow variations of 1 m/day (365 m2/yr), 0.1
m/s/day (3.65 (mm/s)2/yr), and 2–10 %/day (0.15–3.65 /yr) in initial position, initial
velocity, and non-gravitational acceleration:
10 April 2015
47
An example of "tight" constraints would allow variations of 0.1 m/day (3.65 m2/yr), .01
mm/s/day (0.0365 (mm/s)2/yr), and 1 %/day (.0365 /yr) in the orbital parameters:
mar_svs all 3.65 3.65 3.65 .0365 .0365 .0365
mar_rad all .04 .04 .04 .04 .04 .04 .04 .04 .04
To invoke the Markov process for an individual satellite the command is, e.g.,
mar_svs prn_02 3.65 3.65 3.65 .0365 .0365 .0365
mar_rad prn_02 .04 .04 .04 .04 .04 .04 .04 .04 .04
You can allow different values to be applied for different period of time by specifying in
the globk command file an auxiliary file:
svs_marf svs.emed_markov
where Dur is the duration in days over which this alternative set of Markov parameters
should apply. As many as entries as desired can be put into the file.
The rules and requirements for setting a priori coordinates and velocities in GAMIT and
GLOBK analyses can be quite confusing because the needs are different at different stages
and in different contexts. The most important concept to keep in mind is that reliable
estimation of precise coordinates from both the phase data (GAMIT/solve) and loosely
constrained coordinates and their covariances (globk or glorg) assumes that the adjustment
from the (original, GAMIT) a priori is “small”, that is that there is insignificant non-
linearity in the adjustments. Just how small the adjustment of a particular parameter needs
to be depends on the functional dependence of the parameter and its correlation with other
parameters. A conservative assumption for station coordinates is a convergence rate of
1:1000; that is., the adjustments need to be less than 0.5 m to achieve 0.5 mm precision in
the estimated value. Hence, it is imperative that you iterate your phase solution (using, for
example, the AUTCLN Postfit = R option in the GAMIT sestbl.) so that the a priori used
for the solution written into the H-file differs from the final estimate by no more than a
few decimeters.
10 April 2015
48
There are two utilities that are quite helpful in handling a priori coordinates. The first is
glist (see Section 5.1) which will check the a priori coordinates for sites in each h-file in a
gdl list with those from the first file in which the site appears, or with those from a
specified apr file. For this reason (and many others) you should always run glist before
running glred or globk. The second helpful utility is unify_apr, which alllows you to
merge apr files while reconciling velocities of renamed or nearby sites so that they are all
the same in an output apr file.
There are two types of output produced in running globk/glred. The first is the "log" file,
which contains the effect on the solution (usually loosely constrained) as each new h-file
is added. The second is the "print" file, generated also by glorg, which contains the
estimated parameter values. To illustrate the interpretation of these output files, we use as
examples first the combination of regional and global data for a 10-day survey in the
Salton Trough / Riverside County ("STRC") region of southern California from March,
1991, and then its combination with data from other GPS surveys and VLBI observations
acquired between 1984 and 1997.
The log file for the STRC91 survey is shown below. Because the global tracking network
was sparse in 1991, it is particularly advantageous to estimate initial conditions and
parameters of the GPS orbits by combining the data from several days. In this case, we
estimated parameters for three overlapping arcs, each using data from 4 or 5 (24-hr) days.
Within each arc we allowed the initial conditions and radiation-pressure parameters to
have stochastic (Markov) variations from day to day. This scheme is illustrated by the
grouping of h-files in the log file below, in which we have combined h-files representing
24 hrs of global data and 10 hrs (20:44-08:40 UTC) of regional data. The first orbital arc
(GAMIT T-file) spanned days 66–69 (7–11 March) with IC epoch 12h UTC on day 67
(year 91.1814). Data used to estimate the initial conditions and parameters included
global data (h-files named _glob with the mid-point time 11:59) from days 66–69 and 10-
10 April 2015
49
hr regional data (h-files named _strc with mid-point time 02:43) from days 66–68 (the
latter ending at 08:40 on day 69).
Updating SV ephemeris epoch by 91.1814 years
Global 1 using 3.7 Mb. Running time 2.00 Scaling by 1.000 1.00000000
For mgloba.066 Glbf ../glbf/glob1/h9103071159_glob.glr Chi**2 NP 249 is 0.370
Orient_adj. (mas) 1991 3 7 0.50 91.25 -0.46 92.29 0.8 94.48
Global 2 using 2.9 Mb. Running time 8.00 Scaling by 1.000 1.00000000
For mstrca.066 Glbf ../glbf/local/h9103080243_strc.glx Chi**2 NP 177 is 0.293
Orient_adj. (mas) 1991 3 8 -1.95 88.15 -3.07 84.33 2.2 91.33
Global 3 using 3.7 Mb. Running time 11.00 Scaling by 1.000 1.00000000
For mgloba.067 Glbf ../glbf/glob1/h9103081159_glob.glr Chi**2 NP 249 is 1.094
Orient_adj. (mas) 1991 3 8 -3.39 86.86 6.81 82.66 -4.2 90.48
Global 4 using 3.0 Mb. Running time 17.00 Scaling by 1.000 1.00000000
For mstrca.067 Glbf ../glbf/local/h9103090243_strc.glx Chi**2 NP 183 is 0.603
Orient_adj. (mas) 1991 3 9 0.91 85.37 -6.22 78.47 -2.3 89.08
Global 5 using 3.8 Mb. Running time 21.00 Scaling by 1.000 1.00000000
For mgloba.068 Glbf ../glbf/glob1/h9103091159_glob.glr Chi**2 NP 258 is 0.902
Orient_adj. (mas) 1991 3 9 1.55 83.62 -4.13 77.46 -8.0 88.43
Global 6 using 2.9 Mb. Running time 26.00 Scaling by 1.000 1.00000000
For mstrca.068 Glbf ../glbf/local/h9103100243_strc.glx Chi**2 NP 168 is 1.110
Orient_adj. (mas) 1991 3 10 1.10 82.96 -5.79 75.64 -11.2 87.87
Global 7 using 3.8 Mb. Running time 30.00 Scaling by 1.000 1.00000000
For mgloba.069 Glbf ../glbf/glob1/h9103101057_glob.glr Chi**2 NP 258 is 0.696
There are three lines for each h-file used in the solution. The first gives the sequence
number, size, run-time, and scale factors for the file. The second line is the most useful
for evaluating the solution. It includes the GAMIT m-file name (which includes,
conveniently, the day number), the binary h-file name (constructed from the GAMIT file
name but with the date given as year, month, day, hour, minute), the number of parameters
(NP) and the chi-square increment per degree of freedom when the data are added to the
solution. If no tight constraints have been placed on the a priori values of the parameters,
the first file should have a small chi-square value. As subsequent data are added, the
values will increase to reflect the level of incompatibility between the newly added data
and the solution from data previously included (see Dong et al., [1998] for the formulas
used and a detailed discussion). An anomalously large chi-square increment in the log file
is the most obvious indication that you have included erratic or poorly modeled data in
your solution. If this occurs you should either omit the h-file (by commenting it out in the
.gdl file) or return to the phase processing to find the source of the problem. If there is a
10 April 2015
50
consistent incompatibility between the global and regional h-files, there may be a model
inconsistency between the two analyses (e.g., different antenna heights or antenna phase-
center models). The third line gives the adjustment to Earth-orientation parameters as the
data are added. The order is x-pole, x-pole sigma, y-pole, y-pole sigma, UT1, UT1 sigma,
all in milli-arcseconds (mas). In this example, the uncertainties are all large because we
have not yet defined the orientation of the frame (done later with glorg), but the
adjustments are nevertheless small, indicating that the a priori orientation of the satellite
orbits is consistent with the x, y, and UT1 values in the in_pmu file. Whenever the
reference epoch of the initial conditions changes, there is an extra line (Updating SV
ephemeris..) with the time since the last set of ICs, given in years. Thus the transition to
the second arc (epoch 12h on day 70, 3 days or 0.0082 years later than the epoch of the
first arc) is indicated by the first line of the next group of h-files:
Note that one of the regional h-files in each of the last two groupings has been
downweighted (rescaled) to reflect poor consistency with the rest of the solution. These
(approximate) weightings were determined from the nrms values of the GAMIT solutions,
the day-to-day repeatability of coordinates (glred analysis),.and the (globk) chi-square
increments from an initial (unweighted) combination. In this solution, we have also
varied the level of Markov perturbations allowed for individual satellites for specific spans
(using an svs_marf file) based on the differences in initial conditions estimated for each
day from the global h-files (also in a glred analysis). With the h-file rescaling and chosen
level of Markov perturbations, we have achieved a near-unity level of chi-square
increments for all of the files input to the solution.
The second type of output from the run will be a summary of the final solution, including
estimates and uncertainties of the parameters and various representations of these
parameters (e.g. baseline components). If you invoke glorg from within globk to define
the reference frame, as suggested in Sections 3.3 and 3.4, then you will get two versions of
the solution file—one from the globk solution (the .prt file in the globk command-line
arguments) and one from the glorg solution (the .org file in the globk command file).
Since the globk output (in this scheme) is loosely constrained, only the height and baseline
length components have small enough uncertainties to be useful for careful evaluation.
Examining the globk output is useful mainly if the glorg output indicates a problem with
the solution and you want to determine if the source is in the data or the constraints. Thus,
in this mode, you should normally keep the globk output to a minimum (setting no options
for prt_opt—see Section 3.1) or suppressing it entirely using prt_opt NOPR. For
purposes of illustration, however, we show below some detail of both the globk (prt) and
glorg (org) outputs:
---------------------------------------------------------
GLOBK Ver 4.16S, Global solution
---------------------------------------------------------
10 April 2015
51
There were 670124 data used, 0 data not used and 670124 data total
There were 441 global parameters estimated
There were 72 stations, 0 radio sources, and 15 satellites
COSEISMIC characteristics
# CODE Static sigma Spatial Sigma (Depth/Dist)^2
North East Height (m) North East Height (m)
1 LA 1.0000 1.0000 1.0000 1.8000 1.8000 0.7000
2 NR 1.0000 1.0000 1.0000 1.8000 1.8000 0.7000
PRE-SEISMIC characteristics
# CODE Dur Static Process Spatial Process (Depth/Dist)^2
(days) North East Height North East Height
(mm^2/day) (mm^2/day)
1 LA 0.0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
2 NR 0.0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
POST-SEISMIC characteristics
# CODE Dur Static Process Spatial Process (Depth/Dist)^2
(days) North East Height North East Height
(mm^2/day) (mm^2/day)
1 LA 0.0 0.1000 0.1000 0.1000 1.8000 1.8000 0.7000
2 NR 0.0 0.1000 0.1000 0.1000 1.8000 1.8000 0.7000
10 April 2015
52
10 April 2015
53
The first part of the file summarizes the input data and commands, including a list of the
station renames and earthquakes specified (but not necessarily applied) by the eq_file.
The renames listed in the example are changes made necessary by inconsistencies
between the original (GAMIT) processing and the current solution. We also commonly
use this feature to remove a station for one or more days (e.g., ALGO_GPS -> ALGO_BAD,
where ALGO_BAD would be excluded from the solution by the use_site command). This
section also includes the final chi-square per degree of freedom for the solution before
constraints are added. Next, if the PSUM print option is set, would be the north, east, and
up adjustments to station positions. These are omitted here in the loose globk print but
are discussed below for the glorg print file. Always printed are the parameter
adjustments. The coordinate estimates are given both in Cartesian and local
representation. Both here and in the station or baseline summary sections, the north and
up adjustments are computed conventionally; i. e., north is the product of the adjustment
in geodetic latitude by the semi-major axis of the ellipsoid (see
kf/includes/const_param.h for ellipsoid definition) and up is the adjustment in geodetic
height. The east adjustment, however, is unconventional: the adjustment in longitude
(measured east from Greenwich) is multiplied by the radius of the small circle at the
nearest 1 degree latitude line of the station. This scheme keeps the adjustment in the east
value from being affected by changes in latitude. The estimates of orbital and Earth
rotation parameters (EOPs) are self-explanatory, but note that in a globk solution to
combine many days of data, in which new initial conditions and EOPs are estimated for
each day, the estimates represent the solution from only the last day and are therefore of
limited value. The final sections of the print file express the coordinate estimates in
terms of baseline length and components. These appear only if BLEN has been set in
prt_opt and are again omitted in this example.
Shown below is the glorg print file for the same run. It begins with a report of
application of generalized constraints to establish the reference frame ("stabilization").
Recall that glorg is minimizing, in an iterative scheme, the departure from a priori values
of the coordinates of a selected set of stations while estimating a rotation and translation
of the frame. The first four lines echo the parameters used to decide whether a station is
retained at each iteration of the stabilization scheme. The first line indicates that only
50% of the weight for a station may be altered in iteration, thus preventing the ratio of
weights from becoming too high. The third line indicates that heights are downweighted
by a factor of 10 relative to horizontal coordinates. The second line and the second
column of the fourth line indicate that a station is removed if its residual becomes more
than 4 times the rms of the fit (after application of relative weights) but not if its residual
is within 12 mm (4 times the Min Position value of 3 mm). The first column of the
fourth line establishes a floor for the ratio tolerance (2.0 here) used to remove a station
which has a larger-than-average height uncertainty (see the cnd_hgtv command). Height
10 April 2015
54
sigma is used as the primary condition at the first iteration since the horizontal
coordinates will not be well determined until after initial stabilization.
STRC91 combination with multi-day stochastic orbits
+++++++++++++++++++++++++++++++++++++
+ GLORG Version 4.04S +
+++++++++++++++++++++++++++++++++++++
==========================================================================================================
Starting stabilization iteration 1
For 8 sites in origin, min/max height sigma 59.16 87.33 mm; Median 67.11 mm, Tol 7.94 mm
Removing YELL_GPS from orgin condition, height sigma 87.33 mm, Ratio Tol 2.000
=========================================================================================================
Starting stabilization iteration 2
For 7 sites in origin, min/max height sigma 59.16 76.20 mm; Median 60.01 mm, Tol 5.00 mm
Removing MADR_GPS from orgin condition, height sigma 73.96 mm, Ratio Tol 2.000
Removing MOJM_GPS from orgin condition, height sigma 73.52 mm, Ratio Tol 2.000
Removing DRAO_GPS from orgin condition, height sigma 76.20 mm, Ratio Tol 2.000
In this example, we have allowed two iterations of the reference frame solution (there is
little harm, and often gain in allowing three or four). There were initially 8 stations
specified in the glorg stab_site list. Yellowknife (YELL_GPS) is removed prior to the
first solution because the difference between its height uncertainty (87.33 mm) and the
median uncertainty (67.11) was more than twice the difference between the median and
minimum (59.16 mm) values. With 7 stations remaining, the rms fit is 13.9 mm. At the
next iteration, three additional stations—one within California (MOJM) and two outside
(MADR and DRAO)—are removed because their heights uncertainties are now more than
twice the difference between the median and minimum values. This has reduced the rms
10 April 2015
55
of the fit to 3.6 mm, but the frame is now defined by only four regional stations. This
result is not what we desired, and it could have been prevented by setting a value of at
least 8 mm for the first argument of the stab_min command (since the difference of the
height sigmas of these stations and the median is 16 mm and the ratio tolerance is 2.).
Next in the glorg print file is a repeat of the files and command used in the globk run. In
the earthquake list, however, only those used are listed (i.e., those with epochs before the
data epoch, none in this case).
---------------------------------------------------------
GLOBK Ver 4.17S, Global solution
---------------------------------------------------------
-------------------------------------------------------------------------------
10 April 2015
56
For the glorg print we have specified PSUM as an option, so we get a more readable table
of the adjustments and uncertainties of the east, north, and up coordinates for each
station. This table is the most useful for evaluating the solution and contains the values
later extracted by ensum (invoked by sh_globk_scatter) in order to generated statistics
and plot station-coordinate repeatabilities. The column marked RHO in the coordinate
adjustments (Rne in the baseline component estimates) gives the correlation between the
north and east estimates; this is necessary to compute horizontal uncertainty ellipses. As
elsewhere in globk, the stations are ordered by longitude, so that (usually) nearby stations
are grouped together in the list:
SUMMARY POSITION ESTIMATES FROM GLOBK Ver 4.17S
Long. Lat. dE adj. dN adj. dE +- dN +- RHO dH adj. dH +- SITE
(deg) (deg) (mm) (mm) (mm) (mm) (mm) (mm)
355.750 40.429 295.7 214.8 120.1 149.2 0.894 -182.4 48.7 MADR_GPS
288.507 42.613 3.3 329.1 13.1 109.0 0.125 -131.4 25.6 WSFM_GPS
279.616 25.614 105.6 308.3 40.5 90.8 0.954 5.2 19.2 RICM_GPS
245.519 62.481 -314.4 44.2 89.4 10.2 -0.468 -180.7 26.9 YELL_GPS
245.519 34.044 313.5 -147.7 5.3 5.9 -0.286 201.7 13.7 ENDD_GPS
245.193 30.931 18.1 3.7 10.9 4.9 0.614 81.4 16.1 SFBC_GPS
244.280 33.664 -2.4 3.5 0.8 1.6 0.128 21.5 2.4 BLAC_GPS*
244.236 33.834 -57.0 47.6 1.3 1.8 -0.104 290.3 7.2 JTRE_GPS
244.204 32.790 -2.3 -1.3 3.2 2.8 -0.438 -27.2 3.1 OCOT_GPS*
243.590 33.039 -49.1 38.9 3.5 2.7 0.123 315.9 12.9 SD16_GPS
243.577 32.892 0.0 2.3 2.7 1.9 -0.043 32.6 3.7 MONU_GPS*
243.569 33.870 -61.0 38.8 1.3 1.6 0.043 281.0 7.6 EDOM_GPS
243.542 33.612 4.5 -4.4 0.9 1.4 -0.527 -26.6 2.9 PIN2_GPS*
243.511 33.839 -60.8 34.3 1.2 1.7 0.016 284.5 6.5 PSAR_GPS
...
18.938 69.663 457.0 159.4 141.2 113.7 0.910 -270.5 50.1 TROM_GPS
12.879 49.145 494.5 202.6 144.6 127.7 0.877 -1082.8 151.8 WETM_GPS
The stations marked by an asterisk (*) are those used in stablization. Note that since the
reference frame stabilization used only stations within California, only stations in this
region (longitudes 243–245) have small horizontal uncertainties. Following the position
summary is a list of all the parameter adjustments, as in the globk print file:
PARAMETER ESTIMATES FROM GLOBK Vers 4.17S
# PARAMETER Estimate Adjustment Sigma
1. MADR_GPS X coordinate (m) 4849202.2333 -0.2576 0.0881
2. MADR_GPS Y coordinate (m) -360328.9148 0.3161 0.1266
3. MADR_GPS Z coordinate (m) 4114913.0778 0.0451 0.1236
Unc. MADR_GPS 4849202.2333 -360328.9148 4114913.0778 0.0096 0.0219 -0.0034 1991.207 0.0881
0.1266 0.1236
Loc. MADR_GPS N coordinate (m) 4500553.7237 0.2161 0.1492
Loc. MADR_GPS E coordinate (m) 30144706.9592 0.2962 0.1201
Loc. MADR_GPS U coordinate (m) 829.2590 -0.1841 0.0487
NE,NU,EU position correlations 0.8939 0.1922 -0.1166
The line beginning with Unc.contains the values of the coordinates for the epoch at which
the position and velocity are uncorrelated—the "weighted" midpoint of the data span if
there are no a priori constraints applied to the velocity components. In this single-survey
solution, in which no velocities are estimated, the values on the Unc.line are the same as
the lines above. Note that grep'ing on the lines beginning with Unc., and then removing
these characters from the output will produce a list of coordinates (and velocities) in the
appropriate format for the apr_file. Script sh_org2vel will also generate an a apr_file
from the glorg output.
10 April 2015
57
To illustrate stablization and the output table obtained when velocites are estimated, we
shown below the glorg print file for a combination of all of the GPS and VLBI data
acquired in southern California, and the coincident global tracking between 1974 and
1997:
+++++++++++++++++++++++++++++++++++++
+ GLORG Version 4.04S +
+++++++++++++++++++++++++++++++++++++
===========================================================================================
Starting stabilization iteration 1
For 12 sites in origin, min/max height sigma 107.04 120.55 mm; Median 115.30 mm
For 12 sites in origin, min/max dh/dt sigma 6.61 15.88 mm/yr; Median 11.53 mm/yr
============================================================================================
Starting stabilization iteration 2
For 11 sites in origin, min/max height sigma 107.04 120.55 mm; Median 116.08 mm
10 April 2015
58
YAR1_GPS 1.21 TROM_GPS 1.13 WETT_GPS 1.12 ONSA_GPS 0.78 KOSG_GPS 0.93
For 33 Position Iter 2 Pre RMS 0.0599 m; Post RMS 0.0019 m
For 11 sites in origin, min/max dh/dt sigma 6.60 15.88 mm/yr; Median 11.67 mm/yr
In this solution we have defined the reference frame using 11 global stations for which
we have GPS and/or VLBI data over much of the period covered. When we are
estimating velocities, the position results are of secondary importance (and don't affect
the velocity estimates very strongly; see Feigl et al. [1993]). The 3-diminsional (with
vertical downweighted) rms of the velocity residuals of the 11 stations (essentially the 22
horizontal components) with respect to ITRF96 is 0.6 mm/yr, an excellent fit. The
stabilization wrms and nrms for each component is given as part of the velocity and
position summaries farther down in the file. With recent data from the 20–50 IGS core
stations, you should be able to obtain a fit at the level of less than 1 mm/yr in horizontal
velocity and 2–7 mm for position with appropriate selection of stations and editing of the
quasi-observations.
For this solution we have equated the horizontal velocities of most of the collocated GPS
and VLBI stations. The list of chi-square increments from applying each equate gives
you a good idea of where in your data set there are inconsistencies:
Rotating into local coordinates for equates
If an equate is used to tie together the velocity of two stations, one of which has only one
epoch of observations (as, e.g., a renamed station after an earthquake), then the chi-
square increment will always be small. If there are two stations, each with a long span of
independent data, as for example the Owens Valley VLBI (OVRO_130) and GPS
(OVRO_GPS) stations in this solution, the chi-square increment may be large and indicates
10 April 2015
59
the level of inconsistency between the two data sets. The small chi-square increment for
the equating of the Black Butte VLBI (BLKB7209) and GPS (BLAC_GPS) stations indicates
that the estimates are consistent (though the GPS estimate in this solution is relatively
weak). There is an apparent inconsistency between the pre-Landers velocity (now
representing both the VLBI and GPS data) and the velocity estimated from only post-
Landers GPS data (BLAC_GLA, renamed from BLAC_GPS automatically as a result of the
eq_def command). At the bottom of the equate list is the chi-square per degree of
freedom for the solution after the equates have been applied. If your noise model is
correct, this value should be close to unity.
The next section of the print file is again the globk solution summary:
---------------------------------------------------------
GLOBK Ver 4.16S, Global solution
---------------------------------------------------------
COSEISMIC characteristics
# CODE Static sigma Spatial Sigma (Depth/Dist)^2
North East Height (m) North East Height (m)
1 JT 0.1000 0.1000 0.1000 0.1000 0.1000 0.1000
2 LA 1.0000 1.0000 1.0000 1.8000 1.8000 0.7000
3 NR 1.0000 1.0000 1.0000 1.8000 1.8000 0.7000
10 April 2015
60
PRE-SEISMIC characteristics
# CODE Dur Static Process Spatial Process (Depth/Dist)^2
(days) North East Height North East Height
(mm^2/day) (mm^2/day)
1 JT 0.0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
2 LA 0.0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
3 NR 0.0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
POST-SEISMIC characteristics
# CODE Dur Static Process Spatial Process (Depth/Dist)^2
(days) North East Height North East Height
(mm^2/day) (mm^2/day)
1 JT 0.0 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000
2 LA 0.0 0.1000 0.1000 0.1000 1.8000 1.8000 0.7000
3 NR 0.0 0.1000 0.1000 0.1000 1.8000 1.8000 0.7000
The experiment list here gives an example of intermediate combination of h-files and also
the use of inverse sorting (srt_dir -1). The first file listed has all of the GPS data after
the Landers earthquake (i.e., 1992.5–1998.0); the second the VLBI data (1980.0–1994.5;
and the third, the GPS data prior to Landers (1986.4–1992.5). We stacked them in
reverse time order so that the strongest data would be accumulated first, a procedure that
enhances numerical stability. When velocities are estimated, their summary table appears
first in the output of results:
10 April 2015
61
The E & N Rate and E & N Adj. columns give, respectively, the total horizontal
velocity in the defined frame and the adjustments from the a priori values. If the plate or
assign_p commands have been used, however, the adjustment columns no longer give the
adjustments with respect to the values (frame) of the apr_file, but rather residuals with
respect to the plate defined for that site.
SUMMARY POSITION ESTIMATES FROM GLOBK Ver 4.16S
Long. Lat. dE adj. dN adj. dE +- dN +- RHO dH adj. dH +- SITE
(deg) (deg) (mm) (mm) (mm) (mm) (mm) (mm)
355.751 40.429 -26.9 14.5 13.7 13.5 -0.003 7.6 109.5 ROBLED32
355.750 40.429 1.2 -1.5 1.5 1.3 0.023 7.6 44.7 MADR_GPS*
355.749 40.427 14.4 -11.7 13.5 13.4 0.013 -10.9 14.0 DSS65
...
288.512 42.623 7.2 -3.7 10.2 10.0 -0.007 -13.3 13.4 HAYSTACK
288.512 42.623 290.2 152.4 34.8 22.1 0.196 -859.2 829.6 HAYS_GPS
288.507 42.613 43.6 11.9 3.8 2.3 0.052 -2.0 17.7 WSFM_GPS
288.507 42.613 100.5 46.8 21.8 15.3 -0.172 -343.2 970.4 WSFD_GPS
288.506 42.613 5.7 -3.7 10.2 10.0 -0.007 -5.4 13.4 WESTFORD
...
244.280 33.664 -2.8 -12.6 1001.6 1001.6 0.000 74.1 1001.1 BLKB7269
244.280 33.664 62.2 -27.8 2.9 2.0 0.023 -81.4 130.6 BLAC_GPS
244.280 33.664 100.6 -43.7 2.7 2.8 -0.052 67.4 98.3 BLAC_GLA
...
5.810 52.178 -1.7 0.8 1.2 0.9 -0.002 20.0 33.6 KOSG_GPS*
1.483 43.559 -681.0 244.6 21.6 21.4 0.014 -14.3 28.9 TOUL7608
The small adjustments (< 0.5 mm/yr) away from the a priori (ITRF96) values for the
Westford/Haystack stations, which were not used in stabilization, is a comforting check
on the reference frame and the solution as a whole. Note that all of the stations for which
horizontal velocities were equated have the same adjustments and estimated values. If
this is not true, then most likely you have failed to make the a priori values of velocity the
same in the apr_file.
In this multiyear solution we have allowed the heights of some of the stations to be
stochastic in order to render the estimates of horizontal positions and velocities
insensitive to blunders in recording the heights of antennas. This causes the sigmas on
height rates to be large (~90 mm/yr in the example). Allowing stochastic heights
compromises your ability to detect problems in the solution but does not weaken
significantly the estimates of horizontal positions and velocities. It should be avoided if
possible but used if necessary. Downweighting the heights at the offending epochs using
the sig_neu command is a more robust alternative to stochastic noise.
10 April 2015
62
Several categories of error messages are generated by globk. The first are system errors
associated with missing or incorrectly formatted files. These have the form
and can usually be traced to an incorrect path or filename in the command file.
The second type of error results from the inability of the program to decode an entry in
the command file; e.g.,
This highly generic message generated by multiread can indicate a misspelling of the
command, a station mentioned in the command not being present in the solution, or an
unexpectedly short list of tokens. In the example, shown the problem is the last of
these—the apr_wob command requires 8 arguments and has only 6. In this case, no harm
is done since the last two are unused and can be ignored. In some cases, there are traps
coded that prevent the multiread message from occurring. For example, if you do not
include a priori constraints for all the possible radiation pressure parameters (9) in the
apr_svs or mar_svs command, globk recognizes that you might have entered them
separately with the apr_rad or mar_rad commands:
**WARNING** 11 arguments missing from MAR_SVS command. OK if MAR_RAD used
**WARNING** 2 arguments missing from APR_RAD command. OK if APR_SVS used
All of the errors mentioned so far are most likely to occur at the beginning of a run,
when globk scans the command file and the input h-files. One other potential problem
can also be detected at this stage—a station included in the h-files for which you have no
entry in the apr_file:
If a station is missing from the apr_file, globk will use as a priori values of the
coordinates those on the first h-file, so this message need not cause alarm. However, if
you plan to equate adjustments of the coordinates or velocities with those of another
station, or use the station in glorg to define the reference frame, then you should make
sure that the apr_file has correct and matching entries for the station(s).
Once the filtering of the data has started, there are warnings, sometimes accompanied by
action, whenever the h-file being read is inconsistent with the Kalman filter estimates up
to that point or with the a priori values of the parameters. Before adding the new data,
globk first compares the estimated values of the parameters in the h-file with the a priori.
10 April 2015
63
If they differ by more than the tolerance set by the second argument of max_chii (see
Section 3.1), globk will print a message of the form
BAD PREFIT coordinates for site HART_GPS Diffs from apriori -14.911 7.236 -2.139 m
This usually means that the value in the apr_file is wrong. If the differences are of order
tens of meters and the coordinates are not being constrained or used in glorg for
stabilization of the reference frame, then no harm may be done. It's a good idea to
updates the coordinates in the apr_file, however, from the results of your solution. A
similar message can be generated for Earth orientation values, indicating an error in the
in_pmu table. An example is
With the new scheme of generating a priori values for the satellite parameters directly
from the h-files (make_svs command), you should never get a warning about
inconsistencies in the orbital parameters.
Large Rotation removed: Input EOP estimates 204.192 -87088.429 -417.227 (Xp,Yp,UT mas)
dPosition estimates 42249.248 221.837 143786.203 (Xp,Yp,UT mas)
Rotation TOO Large removing. Tolerance 10000.00 mas
Rots (XYZ, mas) 87088.29 -41823.63-144732.24 Trans (m) 20.472976-20.499412 -9.428049
Large Rotation removed: Input EOP estimates -86884.236 87088.288 41832.021 (Xp,Yp,UT mas)
dPosition estimates -41823.627 144008.041 -144732.244 (Xp,Yp,UT mas)
Finally, after checking parameters and applying (or not) a rotation, globk computes the
chi-square increment that would occur if the data from the new h-file were added to the
solution. If this value exceeds the tolerance given by the first max_chii argument, the
data are not included. This feature allows the solution to continue uncorrupted by
outliers among the input h-files. The warning message has the form
The large chi-square increment indicates either a problem with your primary-data
solution (e.g., from GAMIT) or an overly tight constraint on one or more of the input
parameters. If the globk solution has been run with loose constraints on all of the
parameters (as you would do, for example, if you are combining global and regional h-
files), then the problem must be with the data. If, on the other hand, you have
constrained either the station coordinates or orbits, then these constraints may be too
tight. To isolate the problem, try repeating the run first with the apr_file command
commented out (forcing globk to use the values on the h-files themselves) and then with
10 April 2015
64
the apr_svs and mar_svs command commented out, making the orbits effectively loose.
You can also check the adjustments to coordinates and orbits in the print file from the
original solution to see which station(s) or satellite(s) is causing the problem.
As a general warning, Kalman filters are notorious for rounding error, and the particular
formulation used in globk is among the worst. (The motivation for the choice of form
used was driven by the ease of vectoring the computations. On the original computer on
which globk was developed this was critical for generating timely solutions.) The effects
of rounding error can be greatly minimized by not underconstraining parameters (i.e., do
not make the uncertainties of the apriori values of the parameters too large). As
discussed in Herring et al. [1990] and Dong et al. [1998], when a priori constraints are
applied, the critical quantity is the ratio of the a posteriori to a priori variances of a
parameter estimate. The error in adjustment to a parameter value due to the constraint is
given approximately by the adjustment times this variance ratio if the correlations among
the parameters are small. Thus, if station position is determined to 0.01 m and the a
priori constraint was 10 m, then the error in the adjustment due to the constraint is
approximately 10-6 times the adjustment. Thus even a kilometer error in the apriori
position will only bias the estimate by 1 mm in this case. In practice, the sensitivity is
somewhat larger due to correlations, but is probably bounded at n times larger, where n is
the number of parameters estimated. The easiest way to assess the effects is just to apply
different constraints and see what happens. Files containing a priori values can also be
updated if the adjustments are large.
Error messages are usually associated with not finding files. If a VREAD -1 (premature
end-of-file found) error occurs it usually means that either globk did not complete
successfully or that the file containing the solution has been overwritten by another
solution.
Like globk, the glorg command interpreter will issue a generic warning whenever it does
not understand a command, and again this can occur because of a misspelling, missing
station, or too few tokens. The most situation is a command file with equates or renames
for stations that are not present in the current data set. This situation will be noted by the
message
10 April 2015
65
Recently tools have been developed that allow rapid testing of GLOBK solutions using
approximate methods that are much faster than GLOBK itself (mainly due to not using
full covariance matrices). Analyses of 1000 stations with data spanning a decade can be
carried out in a few minutes, thus allowing many iterations for setting up and testing the
solutions. There are two new programs that are used for prototyping solutions are:
(1) tscon which converts a variety of data formats into the PBO .pos format while
allowing a new reference frame realization using techniques similar to glorg
stabilization.
(2) tsfit which fits time series with a variety of models some of which can be
specified in a GLOBK eq-file format.
The general idea of the solution prototyping is to generate an earthquake file and a list of
stabilization sites that can be used in both velocity and time series analysis in globk and
glred runs. Tsfit can also be used to generate apriori coordinate files for use in tscon and
globk/glred. Both tscon and tsfit can read standard globk earthquake and apriori
coordinate files (including EXTENDED entries). The programs do not manipulate
covariance matrices, so it assumed that an initial time-series solution exists with
stabilized coordinates (i.e., the output of a glred run with stabilization).
To use these new programs, the basic sequence is to first run glred/glorg to generate time
series with the PBO print option set. This solution might for example use ITRF2008 sites
for stabilization, or for more regionally focused networks, globk might be used for a
velocity solution and the good sites from this analysis used as the stabilization sites in the
glred /glorg run. There is a "catch-22" here in that knowing which sites are well behaved
requires generating time series first, so these approaches tend to be iterative with the list
of good sites being determined from their behavior in different analyses. Once the initial
time-series are generated, tscon can be used to generate new time-series with different
stabilization sites and with different apriori coordinate models than those used in the
original run. Analyses of these time series can be carried out using tsfit to estimate new
apriori coordinate models and additional parameters associated with seasonal variations,
earthquake post-seismic deformations and jumps in the time series due to antenna and the
instrument changes and earthquakes. The statistics of the fits to the time series are
generated by tsfit and used to judge the quality of the analyses. The summary file output
by tsfit can be used in sh_gen_stats with the –ts option. Removal of outlier data using an
n-sigma condition can also be preformed by tsfit with the output in standard eq-file
format. The new coordinate apriori files from tsfit can be used in a new reference frame
realization using tscon. Finally the newly generated time series can be used to refine the
analysis more using tsfit. Iterating the reference frame in this manner could lead to some
systematic behaviors and it is ideally best to generate the reference frame with a
globk/glorg solution.
At the completion of the tscon/tsfit process, there should be available an earthquake file
that contains earthquakes, renames for offsets and editing (renames to _XPS), and an
10 April 2015
66
apriori coordinate file with optional EXTENDED entries that should provide a good match to
the behavior of the time series. A refined list of reference frame sites and process noise
models may also have been generated. The earthquake and apriori file and other
information can be used in an updated globk velocity solution or in glred repeatability
time series run. These final globk and glred analyses should run with no major problems
and would be used to generate final results.
The program tscon is used to convert time series acquired from other groups to the PBO
.pos format used for time series analysis by tsview, tssum, and ts_plot.py. It also allows
conversion and refinement of the original reference frame via a ‘re-stabilization’. Input
format currently accepted are ‘XYZ’ files generated for the REASON project by JPL and
SIO, csv files generated by SCEC for earthquake simulation, and PBO csv files. There is
utility program xyzsave that can be used to produce XYZ-file for tscon from one or more
glred/glorg print file if you have failed to set the PBO print option in running GLOBK.
Tscon assumes that the position time series are reported at regular 1-day intervals;
missing days are ok, but not a sub-daily shift in the epochs of the values. (If the PBO
print option was set, tssum can be used to extract the PBO lines from the prt/org files. )
where
<dir> is the directory to put the time series files in.
<prod_id> is product id with the form cen.series_frame.type, where cen is a 3-character
name of the center generating the time series (e.g. jpl or sio) or a special product code
(e.g. aug for Augustine volcano), series denotes the orbits (rapid or final), frame is a 5-
character name for the refence frame (e.g. frame, igs05, snf01), and type is 5- to 9-
character extent describing the solution (maybe omitted or be the same as series.)
Examples are jpl.final_frame, pbo_final_snf01.suppl.
<cmd file> is name of command file to allow frame realization. Optional, use ' ' if no
command file. (If no command file is given, the files are simply converted to pbo-
format.)
<files/file-with-list> is one or more input files ( wildcards allowed), or a the name of
a single file ending in .lst containing a list of files. As with gdl-files, # or * in column 1
of the lst file denotes a comment. Only three types of files are currently allowed:
(1) POS-files are standard PBO time series positions files generated with tssum from
glorg output with the PBO print option, assumed to end in .pos
(2) XYZ files, which are assumed to have names of the form aaaaRaw.xyz where aaaa is
the 4- character site code
(3) csv (comma-separated) files of the type generated by PBO or SCEC, giving
reference positions, adjustments, and possibly uncertainties, assumed to end in .cvs.
PBO has positions, dN, dE dU and sigmas; SCEC has dE dN dU and no sigmas.
10 April 2015
67
The output files will be named with the PROD_ID plus the extent .pos.
Summary of commands:
eq_file <file name> (maybe issued mutliple times)
apr_file <apriori coordinate file> (may be issued multiple times)
stab_site <list of stablization sites> (multiple times)
pos_org <xtran> <ytran> <ztran> <xrot> <yrot> <zrot> <scale>
stab_ite [# iterations] [Site Relative weight] [n-sigma]
stab_min [dHsig min pos] [dNEsig min pos]
cnd_hgtv [Height variance] [Sigma ratio]
time_range [Start] [End] (each in the form YYYY MM DD HH MM)
Standard eq-file for globk with earthquake definitions and site renames for breaks and for
deleting data (_XPS and _XCL). As in GLOBK, may be issued multple times.
Standard globk a priori coordinates file with EXTENDED lines. As in globk may be given
multiple times.
used to include or exclude sites during the specified spans can only be used once per site
in tscon (but multiple times in glorg).
specifies the number of iterations to be performed and the n-sigma editing condition to be
used to determine if a site should be deleted from the stabilization list. Site relative
weight is not used (in glorg, it sets the ratio of constant to site dependent weight; since
the sigmas are already known here, this parameter is not meaningful).
Sets the minimum sigmas to be used in deciding if a site's sigmas are too large to be
included in the stabilization (see cnd_hgtv below)
10 April 2015
68
Sets the height variance relative to horizontal variances in estimating the transformation
parameters. When the height variance is set large, potentially large errors in the vertical
component will have little effect on the determination of the transformation parameters.
Sigma ratio is the multiplier of median-best sigma difference used to decide if the sigma
of a site position is too large for the site to be used in the stabilization.
Allows the time range of data to be specified. The new time series have only this
duration of data in them. NOTE: These times need to match the central epochs of the
timeseries entries to within a few minutes. For normal processing, this means HH MM are
12 00.
Tsfit is a program to fit times series to a variety of parameters (steps, linear rates,
sinusoids, and exponentials). The program reads a PBO-format input file, a command
file, and an GLOBK eq-file containing site renames for earthquakes and other
discontinuities. The outputs are a summary file with estimates and statistics and
(optonally) apr- and eq-files that may be input to GLOBK.
The string NONE may be substituted for the name of the command file if you have no eq-
file and wish to estimate only linear rates. As with tscon, the last entry may be one or
more files or a file containing a list of files.
Name of a globk earthquake file. This file can contain eq_exp commands to estimate
exponential decay after earthquakes (This form is not part of standard the globk
earthquake file.). Editing (through _XPS and _XCL renames) and breaks are implemented.
Complete renaming of site such that the lead 4-character code is changed is not
implemented. Unlike the current version of globk, this command may be issued multiple
times to read more than one eq-file.
periodic <Period>
commands tsfit to estimates sine and cosine terms with the period specified in days. This
command may be issued multiple times to estimate signals with different periods.
nsigma <nsigma limit>
Edit the time series based on a n-sigma condition.
max_sigma <Sig N> <Sig E> <Sig U> meters
Allows limit to be set on sigma of data included in the solutions.
Default values are 0.1 in all three coordinates.
10 April 2015
69
limits the time range of data to be considered; the end date is optional.
detroot <det_root>
String used to name the files generate with parameter estimates, statistics, and editing
reports for each site (one file per site); default is ts_. Use [dir]/det_root to have the
files written into a sub-directory; NONE (upper case) to suppress altogether the writing of
these files.
rep_edits <rename file>
Set to have site edits (rename commands) written into a single file for use in globk (in
addition to the site-dependent files generated with the det_root command.)
real_sigma
Apply the tsview/ensum realistic-sigma algorithm to generate statistics needed needed to
account for temporal correlations in the data and write them into the summary file, which
can be input to sh_gen_stats
velfile <vel file name>
Name of an output file containing velocity estimates in the standard globk velocity file
format.
out_aprf <file name>
Specifies name of a globk a priori coordinate file to be generated from the fits. This file
contains EXTENDED entries if needed and can be used directly in globk or tscon.
out_eqroot <root for Earthquake files> <out days>
Specifies the root part of the name for an output file containing estimates of offsets, and
exponential- and/or logarithmic-decay coefficients for earthquakes specified in the eq-
file. If the <out days> argument is included the total post-seismic motion is computed
that many days after each of the earthquakes. If exponential and log terms are estimated
for the same event (same eq_def code) then they are summed and correlations accounted
for in computing the sigmas of the total motion. The outputs are in globk vel-file format
and can be used with sh_plotvel and velview. The outputs are in globk vel-file format and
can be used with sh_plotvel and velview
10 April 2015
70
5. PLOTTING UTILITIES
There are two varieties of plotting scripts and programs available for analyzing time
series and velocity fields. One group (sh_plot_pos, sh_plotcrd, sh_plotvel, sh_velhist) is
static and uses the public domain Generic Mapping Tools (GMT) available from the
University of Hawaii (http://gmit.soest.hawaii.edu), the other (tsview, velview) is
interactive and uses Matlab executables that are distributed with GAMIT/GLOBK (a few
features will work property only with a full Matlab installation, which requires purchase
of a Matlab license). Use of the GMT scripts is documented briefly in Section 3.4, more
extensively here and in the on-line help available by typing the name of the script. The
Matlab programs are described here briefly but documented more fully on the
GAMIT/GLOBK webpage (http://www-gpsg.mit.edu/~tah/GGMatlab).
sh_plot_pos
This script invokes program tssum to extract coordinates from the glorg print file (.org)
and same them in the form of .pos files (PBO format) for plotting by GMT. For plotting
daily repeatabilities from short survey, it can be invoked with minimal arguments as
sh_plot_pos –f *.org
to read all of the glorg print files in the directory (created, e.g. by sh_glred) and use the
default settings to plot residuals by day-of-year after removing a mean. To remove a
linear slope in horizontal but mean-only in vertical, add the arguments ‘-o 1 –u’. To plot
a long-period time-series from a glred run you might use
By default the pos files are erased after plotting, but they can be kept with the –k option.
Plotting the wrms and nrms histogras of residuals is invoked with –h. See the help file
for additional arguments to use a tsfit command file, plot from pos files, and control the
inclusion and display of values.
sh_plotcrd
This is an older script for plotting time series, extracting the values using ensum and
creating mb_ files for plotting using multibase, and plotting with sh_baseline. The basic
usage is similar to sh_plot_pos
sh_plotcrd -f <files>
but the specific options for controlling the plots are different in many cases. When
iinvoked from sh_glred ( E option), the defaults are appropriate. For generating long-term
repeatabilities, a reasonable, sequence might be
sh_plotcrd –f globk_rep.org –s long –res –o 1 –vert –minnum 3 –col 1 – x 2006.0 2012.0
10 April 2015
71
See the help file for a complete set of options. For now, both sh_glred and tsview will
create/accept mb_ iles used by, ensum/multibase, but this option will be phased out in
favor of pos files after 2015.
multibase
Multibase reads the "values" file created by ensum or bcsum (called by sh_globk_scatter)
and creates separate (mb.*) files for each component of each station so that sh_baseline can
direct them easily to the GMT plotting scripts. To avoid creating plots for stations you don't
want to see (though this is dangerous!) or to keep the number of baseline plots to a
reasonable level, you can specify the stations you want using a list, specified in a "sites" file.
The stations are simply listed, singly or in pairs (case-independent, with column one blank):
For example, if the sites file is named baselines, and you want to plot the output of
sh_baseline_scatter:
where -d indicates that the time argument is days (-y selects years). The output files are
named mb_[SITE].datn, where n is 1, 2, 3, 4 for north, east, up, and length, respectively.
sh_baseline
Sh_baseline reads the mb.* files created by multibase and calls GMT programs to create
time-series plots.
Basic usage :
sh_baseline -f mb*
The following additional options are available for producing custom plots:
10 April 2015
72
-sol file : Creates length file. from prt/glorg file. Try to avoid
-sol (takes long time) and use -com. If not issued, the
value from values-file is passed to the plot.
-header : Turn off page and owner line. Good for thesis.
-ps extension : Extent for psbase GMT file name (is not necessary)
Once sh_baseline has been run, the postscript files created ( psbase.*) can be viewed on
the screen using ghostscript or pageview, or sent to a laser printer.
sh_plotvel
Sh_plotvel is an extremely versatile script that can be used to create velocity maps from
globk/glorg solutions, admitting most of the features available in GMT to create an
instructive background map. In its simplest mode, the script allows GMT to determine
the map dimensions based on the coordinates of the stations and creates a velocity map
on a plain background, optionally including political borders for reference. To create a
more eleaborate background, you invoke the sh_plotvel with the name of another script
that you have customized for your area of study.
Basic usage :
<site> is the 4-char station id of reference site for velocities (if omitted,
plot absolute velocities); and
The most important options for specifying the velocities are the following:
-maxsigma value : Limits stations to those with sigmas less than this value
-factor value : Scale the physical size of the velocity arrow by this value
Other options, detailed in the script, allow you to site labels, page orientation, error
ellipses, and arrow scale. Sh_plotvel will also allow you to superimposed, in different
colors, velocity fields from several solutions.
To underlay the velocity field with topographic or tectonic features, you can specify
inclusion of one or more specific maps (-map <map1> <map2> . , or -maplist <file>) or
create for yourself a script that will generate all of the features you need:
10 April 2015
74
-mapscript file : Execute the shell script [file] to produce the map
Templates for this shell script can be found in /com as sh_map_calif, sh_map_china,
sh_map_tien, and sh_map_turk. Within these scripts you prescribe the topography file,
whether or not you want color or a gray-scale, and files for tectonic features and labels.
Separately, for maximum flexibility, you can specify the range (lat/lon) for the map:
-maprange type
which tells sh_plotvel to call script sh_map_elements with the keyword <type> to
select a pre-set region (e.g. europe) There are 13 regions already defined, and you can as
many of your own as you wish. You can also specify a region explicitly using the GMT
range command in the calling sequence; e.g, -R130/170/40/80.
Finally, you can also add to your map specialized features such as an Euler pole and
small-circle describing relative plate motion; and the epicenter, focal mechanism, and/or
slip vector from an earthquake.
Examples :
sh_plotvel -f turkey.prt -s yigi -mapscript sh_map_turk
sh_plotvel -f tibet_001115b.org -ps 000115b -mapscript sh_map_chinatopo -
maprange yunnan2 -maxsigma 10 -u 1 -factor 0.40 -page P -sitefont 8 -arrow_value
20 -D remsite.yunnan
10 April 2015
75
6. AUXILLIARY PROGRAMS
6.1 glist
Glist was designed originally to produce a list of stations included in all of the h-files in
a .gdl list, allowing an easy assessment of the data distribution. It can now accept all of
the files and controls used by globk, allowing you to quickly test a long globk run before
submitting it. Specifically, you can check the coordinates in the h-files against one or
more apr_file(s) i using one or more eq_file(s) under the control of a use_site list, thus
allowing you to catch conflicts and mistakes in station names. It can also be used to
generate an output .gdl file in time-sorted order for use with glred. When executed via
script sh_glist_gmt, the station time summary may be displayed in graphical form.
Runstring:
where <gdl-file> is the name of the file containing the list of global
files to be included in the solution.
<Out-file> is the optional name of an output file (Default is
user's terminal.
<sort-dir> optional value which determines in which order
the data will be time sorted. The default is +1 meaning sort
in ascending time order. -1 may be specified to have data
sorted in decending time order.
<eq-files> one or more eq_files constaining renames and earthquake
definitions; if ore then one, they are separated by :, +, or =.
Adding :A (upperscase) will list the renames in the order they are
applied. RESET may be used as a file name to reset all site extents
to _GPS (RESET may also be used in an eq-file).
<out-gdl> Output GDL file sorted in time order according to
sort_direction
<apr-files> one or more apr_file(s), separated by :, +, or =, used to
check the coordinates in the h-files.
<use-cmds> specifies the name of a file with use_site, use_num, and
use_pos commands.
10 April 2015
76
89 3 31 31 30 20 16 9 33 19 27 23 8 36 10 11 34 28 35 7 /data3/mhm/gpsht/h890331059.gld
90 3 28 2 30 20 9 8 10 11 3 28 1 /data3/mhm/gpsht/h900328040.gld
SUMMARY of occurences
1. WSFD 26 1987.0-1990.2 3.24 2. ALGO 18 1987.0-1990.2 3.24
3. RICH 7 1988.2-1990.2 2.03 4. CHUR 18 1987.0-1988.2 1.22
5. AUST 8 1987.0-1987.4 0.41 6. PLAT 18 1987.0-1988.2 1.22
7. YKNF 13 1987.4-1989.2 1.85 8. MOJA 23 1987.0-1990.2 3.24
9. JPL1 8 1989.2-1990.2 1.00 10. OVRO 30 1987.0-1990.2 3.24
11. PVER 27 1987.0-1990.2 3.23 12. BRSH 5 1987.0-1987.0 0.01
13. COTR 5 1987.0-1987.0 0.01 14. CHAF 1 1987.0-1987.0 0.00
15. SOLI 4 1987.0-1987.0 0.01 16. FIBR 18 1987.0-1989.2 2.25
17. TWIN 4 1988.2-1988.2 0.01 18. SCRE 1 1987.7-1987.7 0.00
21. DEVL 4 1987.0-1987.0 0.01 22. SCRW 3 1987.7-1987.7 0.01
23. MADC 13 1987.0-1989.2 2.25 24. SOLE 5 1987.0-1987.0 0.01
25. GAVI 3 1987.0-1987.0 0.01 26. MILL 1 1987.0-1987.0 0.00
27. LOSP 11 1987.0-1989.2 2.25 28. VNDN 30 1987.0-1990.2 3.24
29. VSLR 1 1987.0-1987.0 0.00 30. BLHL 27 1987.0-1990.2 3.24
31. BLAN 13 1987.0-1989.2 2.25 32. FTOR 19 1987.0-1988.2 1.22
33. KOKE 4 1989.2-1989.2 0.01 34. TROM 7 1988.2-1989.2 1.04
35. WETT 4 1989.2-1989.2 0.01 36. ONSA 4 1989.2-1989.2 0.01
The error mesages associated with glist are usually file related. Warnings about the
apriori values not matching will also be printed when this program is run.
6.2 glsave
This program creates a combined binary h-file from the com_file output of a globk run.
It provides an alternative to the out_glb command in globk.
where <com is the globk common file name (given in the com_file command).
file>
[out global name] is an optional output file name.
[description] is an optional description for the solution. If there are blanks the
description must be enclosed in single quotes (e.g., 'Week 819 run')
These five programs provide a convenient means for extracting coordinate and baseline
information from the print files for globk (usually produced by glred runs) and from back
solution output files. (See also extract and exbrk for more general extraction software,
and multiplot and plot for display software). The program xysum is a utility for getting
or updating coordinate values for the .apr file and and the time-distribution of the
stations; bcsum, blsum, and ensum generate files for plotting; enfit allows you to estimate
functions describing post-seismic behavior and plot the residuals. Specifically:
xysum — extracts and averages the cartesian estimates of station coordinates and
velocities, producing an apr file, a values file for plotting, and a summary file
giving the time distribution of each station in the solution.
blsum — extracts baselines lengths only and produces a summary file with baselines,
wrms scatters about the means, rates of changes and wrms scatters about the
rates; and a values file which contains all baselines length determinations
10 April 2015
77
(sorted by baseline). This latter file may be used in multiplot to produce plots
of the time evolutions of all baseline lengths.
bcsum — extracts baselines and the north, east and up components of the baselines and
produces a summary file, similar to blsum, for each baseline with four entries
per baselines, one each for baseline length, north component, east component,
and up component; and values file which contains the time evolution of
baseline lengths and the baseline components. This file may be used as input
to multiplot.-
ensum — extracts the North, East and Up components of station positions and produces a
summary file and values file similar to blsum. The values file can be input to
multiplot and all components will be plotted.
enfit— extracts the North, East, and Up component of station positions and performs a
fit to the time series for each station, allowing estimation of an offset, rate, and
one or more exponential and periodic functions. This program is useful for
error analysis and also for studying post-seismic relaxation.
For these programs to be used, output options with bit 1 set (i.e, 2 decimal) must be used
during the globk runs.
NOTE: The summary files and values files are overwritten by these programs if they
already exist.
The runstrings for each of these programs is shown below from on-line help files.
XYSUM: Generate globk apriori, summary, and a file containing all site
XYZ values sorted by site and possibly time.
Runstring:
10 April 2015
78
BLSUM: Generate summary and a file containing all the baseline length
values sorted by baseline and possibly time.
Runstring:
where <option> controls the sorting and limits on the number of values
needed for an output to be made. If option contains a
numerical value, then this gives the minimum number of
estimates need to produce an output. If this numerical
value is negative then the baseline entries will be
time sorted before being output to the values file.
(The default value is 0 i.e. all entries are output to
summary file)
<summary_file> is the name of the summary file (one line per
baseline)
<values_file> is the name of file where all the individual baseline
lengths are written, sorted by baseline and optionally
by time.
<Input solution files> is a list of input files. These may be
generated by globk, glbak, solvk or may be previously
obtained values files with the line:
VALUES_FILE
as the first line of the file.
The help file for ensum is similar to that for blsum, and will not be given. Bcsum has an
extra output file:
BCSUM: Generate summary and a file containing all the baseline length
values sorted by baseline and possibly time.
Runstring:
<component summary> is the file containing the summaries for length (L),
North (N), East (E) and height (U).
Runstring:
where <option> has the same meaning as in ensum. A positive numeric value sets
the minimum number of measurements needed for a time series to be included.
10 April 2015
79
Exponential function
--------------------
EXP <date> <tau> <apriori sigma> [tau sigma]
where <date> is yy mm dd hh min for start of exponential,
<tau> is the decay time in days
<apriori sigma> is apriori contraint to apply to estimate in mm.
This command may be issued multiple times to generate results for multiple
decay times.
Periodic function
-----------------
PER <Period> <apriori sigma>
where <Period> is the period in days. The terms have
zero time at 2000/01/01
<apriori sigma> is apriori contraint to apply to estimate in mm.
This command may be issued multiple times to generate results for multiple
periodic terms.
10 April 2015
80
Extract and exbrk are general utility programs for extracting information which have
some type of repeating structure. They allow information to be obtained from multiple
lines in the input and then output on a single line. The two programs are the same except
that exbrk will output a status report if any key on your terminal is touched while it is
running. In response to this status, you have the option of continuing if everything looks
good or aborting the run so that the input control file to extract can be modified. Since
extract/exbrk can extract a number of different types of information for each run, you
also have the option of skipping to next classs of information to be extracted. These
features are very useful when new extract commands file are being developed. They
quickly let you see if the commands are working OK, and which lines the program is
having trouble finding. Because of this key press sensitity, exbrk cannot be run in
background (the program will immediately stop in state waiting for input from your
terminal). Even when run in foreground, the feature also poses a problem if the program
is executed under script control, since any key pressed at any time during the script
execution will cause the status to be printed and the program to wait for response when
exbrk is executed. For these reasons, it is recommened that exbrk be used to check the
extract command files, and then when you want to use these commands in general
processing that extract be used.
Runstring:
EXTRACT Commands
----------------
(Note: all commands may be truncated to minimum unique length, and all
commands must be preceeded by at least one blank)
END -- Tells program to stop reading the command file (EOF has
the same effect)
INPUT -- Name of the input file. Must be given here or in the runstring.
Usage: INPUT my_input_file.txt
OUTPUT -- Name of the output file. Defaults to users terminal. Multiple
input files may be read for output to the same output file
by giving new INPUT commands betweem RUN commands (see below)
without re-giving the OUTPUT command.
DESCRIPT-- Allows the specification of the header record describing each
each of the fields extracted. Note: the description is enclosed
in double quotes (").
Usage: DESCRIPT <field #> "<description>" or
where field # is the number of the field to which the description
applies. (See field command below)
TITLE -- Allows a title to be given to the output file. This line will
appear as the first line in the output file.
Usage: TITLE "<title>" OR
TITLE <nn>
where <title> is the string to be output and must be encloded
10 April 2015
81
in double quotes.
<nn> is an alternive form and line NN of the input file
will be used as the title. NOTE: No field information
will extract until after the <nn> line of the input
file is read.
FIELD -- Tells the program about the information to be extracted from
the data file. This is a complex command which gives the
user a great deal of flexibility in the information extracted.
The format of the command is:
where:
# is the field number. EXTRACT allows the user to specify
upto to 10 fields of information to be extracted.
There three types of field (See type below also).
CHaracter -- only one string per field (upto 64
characters long)
Integer*2 -- Upto 32 integer values per field
Real*8 -- Upto 8 real*8 number per field.
If these numbers of arguments are not large enough
then you can extract the information using a number
of fields.
<descriptor> is an Ascii string which tells extract the
EXACT string which must be found in the input file
for it to extract the field data from the rest of the
string.
#_args is the number of arguments in the field to be
extracted (see above for limits)
type is the type of field. Type may CH for charater,
I2 for integer*2, R8 for real*8. (see restrictions
on number of arguments given above).
The next string may be either:
FORMAT to extract the field data using a FTN77
format statement OR
READLINE to extract the field data using free format reads
Indepenent of the use of Format or Readline, the next
argument 0/1 tells extract whether to get the data from
the line imediately following the <descriptor> (option 0),
or from the start of the line (option 1).
When FORMAT is used the 0/1 is followed by the FTN77 format
enclosed in double quotes(don't forget the parentheses
around the format,
When READLINE is used the 0/1 is followed by #_args values
which tell EXTRACT which values for the rest of the line
should be used. For expample, if your input line looked like:
string 120 baseline 200 10 20 0.110 -- Line
1 2 3 4 5 6 7 -- Item numbers
then Items 2 4 5 6 and 7 could be read with R8 or I2 (although
item 7 would be zero in I2 format). Any of the items 1-7
could be extracted with a character field (although only one
item per field.) [If you wanted a character field with the
complete line above, then FORMAT would be the only choice.
The other option for the field command is CLEAR which will clear
the information about the field. Thus this field will no
longer be searched for.
10 April 2015
82
RUN -- Tells extract to process the input file with the current
field information. THIS COMMAND MUST BE GIVEN OR ELSE EXTRACT
WILL DO NOTHING.
NOTES:
------
EXTRACT defaults to field 1 searching for EXPERIMENT DATE: with
the date read with a format. This is used for extracting information
from the SOLVK and GLBAK solution files. This field is also set
for NORESET so that the same exeriment date can be used for many items
from a SOLVK solution.
EXAMPLE: The following extract command file will extract the statistics
. form a SOLVK solution file. NOTE: Any character in column one will
. cause the line to be treated as a comment
. Line below is a comment but could be used to get pre-fit statistics
. instead of postfit. If we wanted to we could do both together.
.field 2 "pre-fit Chi**2/f is" 1 CH readline 0 1
outform 2 "(a20)"
outform 3 "(2x,a20)"
outform 4 "(1x,I5)"
outform 5 "(2x,a12)"
In response to pressing a key exbrk will respond as follows. (The text below shows the
program run line as well.) In this example, the program was allowed to continue after the
first break, and then aborted.
10 April 2015
83
6.5 getrel
Getrel is a program which allows the relative velocities of stations to be extacted from a
globk solution in such a way that they can be plotted using plot with error ellipses. To
use getrel, velocities must be be estimated and glorg run with the output options
brat:svel set . This output will produce the summary of station velocities and the
velocities of the baseline components. Since the baseline components are output for the
western directed baselines only, getrel will reverse the direction on the baseline to make
the velocity components relative to station specified in the input runstring to to the
program. The instructions for using getrel are given in the online help file. Any example
of a plot control file to plot the output from getrel is also given below.
Runstring is:
% getrel <site> <input file> <max_sigma>
These two programs alter existing h-files to achieve binary byte-order compatibility or to
change incorrect information. The first program, swaph, is used to change from BIG-
ENDIAN (HP, Sun) binary to little-endian (PC, DEC) binary:
10 April 2015
84
where < h-files > is the names of the files to be changed, with standard Unix wild-cards
allowed (i.e., swaph h* ). The program will sense the type of machine you are on and
change the bytes only if necessary to be compatible with that machine's architecture. The
files are rewritten in place, and the version number of the h-file, stored internally, is
changed to indicate the te bytes have been swapped.
Program hfupd compares the entries on an h-file with those on a current GAMIT
station.info file or a SINEX file and changes all that do not agree. Because of the high
cost in storage and cpu to read and write a large number of h-files, hfupd is designed to
make the changes in place (taking advantage of a direct-access read/write), overwriting
the old h-file. Since the results of hfupd are non easily reversible, you can/should run it
initially without the -u (update) option to be sure that you know what changes will be
made. .
Options:
-s <sinex file/station.info>
Use the named sinex file or station.info file to check antenna type
and eccentricities. The program reads the complete station.info
file so expect the program to stop for any errors in station.info.
(A Gamit standard routine is used which generates a fatal error, so
you will need to find the problems one-at-a-time). When station.info
is used, antmod.dat and rcvant.dat must be available, either in the
local directory or $HOME/gs/tables.
-e <edit file>
-u Update the hfile. This option must be given for the hfile to be
updated. The hfile is re-written in place so the changes are
permanent.
-p <hf/pmu file>
10 April 2015
85
-h [list:]
Update headers only and not the solution vector. The [list:]
includes a : separated list of quanities to be updated.
ant -- Antenna information
ptd -- Mark file as having pole tide applied without actually
applying the pole tide. These features are useful for correcting
inconsistent information, especially from sinex files (rather than
ascii hfiles which contain information consistent with the
solution). With the pole tide, the sinex file has no information to
indicate that it has been applied. Analysis center reports must be
relied upon for this information.
The following entries may be included in the edit file. All entries
start with at least one blank character. All options are optional
except the site name (and rename site for rename command).
6.7 glbtog
This program will read a globk print file or bak file and generate a series of g-files that
can
be used in GAMIT processing.
10 April 2015
86
** WARNINGS **
+ This program will overwrite existing gfiles with the same name as
those generated by the program
+ If multiple G-files will be produced then an end numerical value
will be added to the name.
+ Since GLOBK/GLBAK only output orbital elements for those SV's with
data, the gfile produced here may need to be edited to add those
satellites in the xfile headers for which there is no data.
+ Be careful with multiday, stochastic orbits. When these g-files
are used again in GAMIT and globk used to processes the output
files, globk will not know that the orbits are not fully dynamic.
+ This program produces warnings if the radiation parameters deviations
are greater than 30%. It is not recommended for these orbits to be
re-integrated.
+ In addition to the IC values, the sigmas from the Globk solution are
also added to the file. The units of the sigmas are the same as
globk units (meters, mm/sec and unitless). The sigma units are
different to the orbital element units.
6.8 glbtosnx
This program will read globk ver 1.0 and greater binary h-files and write out IGS
standard Solution INdependent EXchange (SINEX) files. The runstring is
glbtosnx <dir> <comments file> <input binary hfile> <output file name>
10 April 2015
87
The format of the comments file is similar to the SINEX itself. An example is given in
head.snx in the $(HELP_DIR) directory. We have augmented the current SINEX format
by entries to allow the DOMES numbers to be defined. These are also given in
head.snx.
where <sys 1> is the name of the file containing the stations
and their coordinates and velocity in system 1
<frame 1> is the frame for this first system. (See frames below.)
<sys 2> is the second (comparison) system. Sys 1 will be
rotated and translated into this frame. Differences
will be given between sys1 and sys2 in this frame.
<frame 2> is the frame for this second system. Same
choices as above. Default NAFD_1990.0 where the
end characters are the epoch of the frame to be
used. (Only used for the out_frame)
<outname> is name of file for output of frame (overwritten)
<out_frame> is the frame for the output field (as above)
<ties> if the file containing station ties. The file is
interpretted as using the second station name in the
tie to generate the position of the first tie. The
ties are only applied to the stations in sys 1. (May
be neglected in runstring---no ties will be used)
<fundamental sites> names of stations to be used for rotation
and translation (names after ties have been applied)
If not given then all stations are used. ALL may be
given as name and all common stations will be used.
A '-' in front of name will stop it being used.
<height wght> Weight to be given to heights in the
10 April 2015
88
The following frame names are supported: PCFC, COCO, NAZC, CARB, SAFD, ANTA,
INDI, AUST, AFRC, ARAB, EURA, NAFD, JUAN, PHIL, NUV-NNR, AM-02, ITRF93, ITRF94.
E.g. NAFD_1993.4 for the output frame would North America fixed with
coordinates aligned at 1993.4. The rates are calculated using NUVEL-1A unless
a ":0" is added to the name (e.g. NAFD:0), in which case NUVEL-1 will be used.
Usage:
10 April 2015
89
Example link_file:
* Include list
* If jplm_gps occurs in both systems include in the alignment
* sites (note: in this file this will result in the site being
* used twice)
jplm_gps
* If e200_bas and egan_gps occur in both files, add to the
* aligment list. (+ at beginning of name is not needed)
+e200_bas +egan_gps
10 April 2015
90
Output
------
The output file first contains the statistics of the alignment of the systems
and the residuals of the sites used in the alignment. These residual lines
start with the letter A (for grepping).and contain the residual velocities at
the alignment sites (dN, dE, dU), the combined sigma of the pairs of velocity
estimates in the residuals (sN, sE, sU), and the contributions of the
transformations uncertainties at these sites (sTN, sTE, sTU).
The second block of the output contains the velocities from System 1 given in
the System 2 frame. The sigmas given here include the contribution from the
uncertainty in the trans-formation parameters.
The final block gives the velocities of the sites in System 2. If a site name
here matches exactly a name from System 1, 3. the entry has a - symbol in the
first column (thus is 4. made a comment).
In both outputs, sites in different systems which are separated by less than
cp_dist will be marked with a * for System 1 and a '+' for System 2 at the end
of the site name. To see which sites will be used for alignment, the following
sequence can be used:
comb.list contains
cp_dist 10000
Then
% velrot sys1,vel nafd sys2.vel nuv-nnr sysout.vel pcfc comb.list
% grep '*$' sysout.vel >! t1.vel
% grep '+$' sysout.vel | awk '{print " "substr($0,2)}' >! t2.vel
% sh_plotvel -f t1.vel -line 0 -f2 t2.vel -line2 0 -color -sitefont 10
generates a plot with only the common sites on it.
NOTE: It may be necessary to remove the '-' form the start of the System 2
lines if the site names match between the two files. We have done this above
with the awk command.
6.10 plate
Program to generate a globk apriori station position file from an existing one with the
velocities replaced by plate motion velocities. The input plate velocty file contains the
rotational velocities of the poles for each station. If a station appears in the apriori file
but not in the plate file, its entry is copied directly to the output file inchanged.
PROGRAM PLATE:
10 April 2015
91
This program reads an apriori global apr file and a file containing
site names and velocity vectors and outputs a new file with the
velocities included. The velocity field is also output in a
format used by sh_plotvel for plotting velocity fields.
Runstring:
% plate <plate file> <Input .apr file> <output .apr file> \
[velocity file] [Refrence frame]
10 April 2015