.. _intro_prod_refframe: 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 :program:`globk` command file tight *a priori* uncertainties on the coordinates (positions and velocities) of one or more sites, e.g. .. code-block:: text 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 :program:`globk` free .. code-block:: text 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 :program:`glorg` to apply generalized constraints ("stabilization" in GLOBK jargon) .. code-block:: text 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 :program:`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 :cite:t:`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 :file:`.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 :file:`igb14_comb.apr`, which is the second IGS realization of ITRF2014 plus the addition of older, no longer used sites from :file:`itrf14.apr`. The :file:`igb14_comb.eq` file that accompanies this :file:`.apr` file has :content:`rename` commands the are consistent with the 8-character site names in :file:`igb14_comb.apr` (or :file:`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 :content:`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 (:content:`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 (:content:`BASELINE` mode in GAMIT) and allow them to adjust implicitly (in the global solution) by omitting the :content:`apr_svs` command in :program:`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 (:content:`use_site`) only the sites you intend to use in :program:`glorg` for stabilization or tectonic frame realization (:content:`plate` command of :program:`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 :program:`sh_get_hfiles`, invoked directly or via :program:`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 :content:`apr_neu` command in :program:`globk`, as noted above, you may want to invoke :program:`glorg` for other reasons and prefer to leave the :program:`globk` constraints loose and apply the constraint using the :content:`force` or :content:`constrain` commands: .. code-block:: text 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. :cite:t:`Altamimi_et_al_2012`), then it is easy to do so simply by substituting in :program:`glorg` (not necessarily in :program:`globk`) one of the rotated ITRF apr files provided in :file:`~/gg/tables/` (e.g. :file:`igb14_comb_eura.apr`). The quality of the stabilization should be identical to one carried out with :file:`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 :content:`plate` command of :program:`glorg`, e.g. .. code-block:: text plate noam algo nlib pie1 rcm5 brmu chur With this command present, :program:`glorg` will estimate the rotation vector (Euler pole) for a block (spherical cap) containing these sites with respect to the stabilization frame. The :file:`.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 :file:`.apr` file) with residuals with respect to the plate prescribed to include that site (the velocity estimates themselves remain in the frame of the :file:`.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 :program:`sh_org2vel` with the :program:`glorg` print file as input and the plate(s) specified with the names used in the :content:`plate` command will produce velocity summary file(s) with the motions of all sites in the solution with respect to each of the plates.