5.4. Realizing a Reference Frame

Although the GPS satellites provide a natural dynamic frame for ground-based geodesy, the doubly differenced phase observations (or equivalently, undifferenced phase with clocks estimated or provided) do not tie a ground station to the orbital constellation at the millimeter level we require for scientific studies. Rather, we define and realize a precise terrestrial frame by applying constraints to one or more sites in our network. GLOBK allows two approaches. The simplest, used also in GAMIT, is to apply in the globk command file tight a priori uncertainties on the coordinates (positions and velocities) of one or more sites, e.g.

apr_neu all 1 1 1  .1 .1 .1
apr_neu algo .001 .001 .003  .001 .001 .003
apr_neu drao .002 .002 .002  .003 .003 .010

This “finite constraints” approach is rarely used in GLOBK, however, because it can distort the network if the assigned constraints are not correct for the a priori coordinates and data in your solution.

A more rigorous approach to frame realization is through “generalized constraints”, in which you minimize the adjustments of coordinates of the frame-defining sites while estimating translation, rotation, and sometimes scale (Helmert parameters). With this approach, all of the reference sites are free to adjust (hence revealing bad data or coordinates) and any frame realized with a particular set of reference sites will differ from a frame realized with another set only in translation, rotation (and scale), with no internal distortion. You enact this approach by keeping the constraint in globk free

 apr_neu all 1 1 1  .1 .1 .1
# EOP loose if estimating rotation in glorg
 apr_wob 10 10 10 10
 apr_ut1 10 10
 mar_wob 3650 3650 365 365
 mar_ut1 365 365
# EOP tight if estimating only translation in glorg
x  apr_wob .25 .25 .1 .1
x  apr_ut1 .25 .1

and invoking glorg to apply generalized constraints (“stabilization” in GLOBK jargon)

 pos_org xtran ytran ztran xrot yrot zrot
 rate_org xtran ytran ztran xrot yrot zrot
# translation-only
x pos_org xtran ytran ztran
x rate_org xtran ytran ztran

Estimating both translation and rotation in glorg is necessary for global and large regional networks and preferred for any network over ~ 50 km in extent. (The scale parameter can usually be omitted—but see the discussion in Dong et al. [1998].) However, estimating rotation in addition to translation is robust only if you have at least six stabilization sites with a good geometric distribution. If there is only one site at the outer edge of the network (i.e. with a long “lever arm”), all of its error will go into the combination of rotation parameters in its direction. When this happens, both the uncertainty and residual of that site will be very small, there will be insufficient redundancy to provide stability to the network, and the stabilization statistics will be less meaningful. When you estimate translation only, you can get by with fewer stabilization sites and the geometry is much less important.

The simplest and most robust approach to frame realization, for all but the smallest networks, is to incorporate into your solution 10 or more sites whose coordinates are included with small uncertainties in the .apr file from the most recent International Terrestrial Reference Frame (ITRF) or its current IGS realization. The GLOBK template command files are set up to use igb14_comb.apr, which is the second IGS realization of ITRF2014 plus the addition of older, no longer used sites from itrf14.apr. The igb14_comb.eq file that accompanies this .apr file has rename commands the are consistent with the 8-character site names in igb14_comb.apr (or itrf14.apr). In your solutions you can realize this frame either by including data from all of the chosen reference sites in your GAMIT processing, run in BASELINE mode with IGS orbits fixed, or by including in your GAMIT processing 3–4 IGS sites (not necessarily reference sites) that will tie your h-file to an h-file generated by MIT or SOPAC from global processing. To be completely rigorous in this latter case, you should include orbit estimation in your GAMIT run (RELAX mode) and allow the global h-file to determine the orbit. However, in practice with current IGS orbits, you can keep them fixed in the regional solution (BASELINE mode in GAMIT) and allow them to adjust implicitly (in the global solution) by omitting the apr_svs command in globk. Whether orbits are estimated implicitly or explicitly for the global network, you need to include a fully global h-file (e.g. MIT GLX or all of the SOPAC “igs” h-files), though you do not have to explicitly estimate the coordinates of all the sites. The principle here is that the global h-file(s) includes all of the information from processing the phase data whether or not the parameters (orbital or site coordinates) are explicitly estimated. Thus you can explicitly estimate (use_site) only the sites you intend to use in glorg for stabilization or tectonic frame realization (plate command of glorg) or which are otherwise important scientifically for your study, thus saving considerable computation time compared with estimating explicitly the orbits and the coordinates of 300+ sites in the global h-files. Using externally generated GLOBK h-files gives you access to a large number of stations without the computational burden of running GAMIT yourself with a large network. The potential disadvantage is that the models you have used may not match those used by the external processing center (some matter more than others) and there is some burden imposed in downloading and storing the files (15–20 Mb per day) on your system. The script sh_get_hfiles, invoked directly or via sh_glred facilitates downloading the files.

If you have a small network with only one or two (or perhaps no) sites with good a priori coordinates, you may be able to realize an adequate reference frame by fixing or tightly constraining one site. This works because the uncertainties and errors in “absolute” coordinates (relative to the satellites) map into uncertainties and errors in relative coordinates (your primary interest) roughly reduced by a factor of the satellite altitude (20,000 km) to the baseline length. So, for example, a 1 m uncertainty (or error) in the coordinates of a constrained site induces an uncertainty (or error) of only ~ 1 mm over a 20 km baseline. (The actual reduction depends on session length and geometry, but for short baselines you have considerable latitude in setting the a priori constraint.) Although you can apply the constraints with the apr_neu command in globk, as noted above, you may want to invoke glorg for other reasons and prefer to leave the globk constraints loose and apply the constraint using the force or constrain commands:

constrain algo npos 0.  .001
constrain algo epos 0.  .001
constrain algo upos 0.  .003
constrain algo ndot 0.  .001
constrain algo edot 0.  .001
constrain algo udot 0.  .003

When generating time series and velocity solutions used to evaluate the quality of the data and your analysis approach, the theoretical definition of the reference frame is not important. It is usually best to carry out these steps in the no-net-rotation (NNR) frame of the ITRF (and strictly speaking, you should use this frame if you are not estimating orbits since it is consistent with the EOPs). Eventually, however, you will want to view the velocities in a frame that is natural for geophysical interpretation, and that is usually with respect to a stable tectonic block near your network. If you want to use the realization of a major plate as determined from the ITRF data set (e.g. Altamimi et al. [2012]), then it is easy to do so simply by substituting in glorg (not necessarily in globk) one of the rotated ITRF apr files provided in ~/gg/tables/ (e.g. igb14_comb_eura.apr). The quality of the stabilization should be identical to one carried out with igb14_comb.apr (NNR) since the relative motions of the sites has not been changed. If you want to realize a plate or smaller rigid block from your own solution, then you can do so using the plate command of glorg, e.g.

plate noam  algo nlib pie1 rcm5 brmu chur

With this command present, glorg will estimate the rotation vector (Euler pole) for a block (spherical cap) containing these sites with respect to the stabilization frame. The .org file print will contain the components and uncertainties of the rotation vector and will replace the velocity adjustments from the stabilization (i.e., with respect to the .apr file) with residuals with respect to the plate prescribed to include that site (the velocity estimates themselves remain in the frame of the .apr file). You can estimate any number of plates in a single solution so long as they are nearly independent and no one of them contains almost all of the sites used for stabilization (this will create a numerical instability). Running the script sh_org2vel with the glorg print file as input and the plate(s) specified with the names used in the plate command will produce velocity summary file(s) with the motions of all sites in the solution with respect to each of the plates.