3.2. Summary of Program Flow
To understand how to set up input controls and evaluate your solution, you need to have in mind the data and solution files produced at each step. The examples below are from the 5-station 2000 February 3rd (day-of-year 034) GPS-only Southern California survey used in previous releases for testing the installation.
File |
Name example |
Description |
RINEX |
|
RINEX observation file, input to makex |
x-files |
|
GAMIT ASCII observation files, similar to RINEX but the start/stop times and sampling interval are the same for all sites; output of makex, input to model. |
c-files |
|
GAMIT binary observation files, contain “\(\text{o} - \text{c}\)”s and partial derivatives as well as observations; output of model, input and output of autcln, input to solve. 6th character increments |
q-file |
|
Full solution report from solve; 6th character |
GAMIT h-file |
|
Loosely constrained solution estimates and covariances from solve. |
GLOBK h-file |
|
Binary h-file for GLOBK, created by htoglb. |
|
|
Solution report from glorg. |
Note that GAMIT files are named with single- or two-digit years and day-of-year and have a required format, whereas GLOBK h-filenames are arbitrary but conventionally named with two-digit year, month, day, hour, and minute.
A full description of the preprocessing steps undertaken by makexp and makex to produce x-files and the coordinate, clock, and orbit files used by model can be found in Chapter 2 of the GAMIT Reference Manual;
naming of c-files and a description of the q- and o-files produced by solve is in Chapter 3.
Of the GAMIT-produced files, only the h-file has more than a one-digit year in its name since it is the only file that is carried beyond the processing for a single survey.
The .org file is described in Chapter 3 below.
It is also useful to have in mind the way the files containing external data, survey metadata, and command files get from their natural homes to the day directory for processing.
“Global” files, which contain information useful for many surveys reside in ~/gg/tables but are linked by sh_gamit into the project tables/ directory (script sh_link_tables) and then into the day directory (script links.day), usually under the same name.
These include:
EOP tables from the IERS |
|
Lunar-solar ephemerides |
|
\(\text{GPST} - \text{UTC}\) |
|
IGS receiver/antenna codes |
|
User-defined receiver/antenna codes1 |
|
Ground antenna mechanical dimensions |
|
Satellite block #s, PRN #s, masses |
|
Ground/SV antenna phase center models |
|
P1-C1, P1-P2 code biases |
|
Empirical ZHD &mapping functions (MF) |
|
Time- and space-dependent ZHD and MF |
|
Ocean loading |
|
Atmospheric tidal loading |
|
Non-tidal atmospheric loading |
|
The particular version of each of these files is specified by the link in ~/gg/tables/ or the project tables/ directory.
For example, the FES2004 ocean loading model is selected by linking otl.grid to otl_FES2004.grid in ~/gg/tables/.
For EOP tables, the source (e.g., IERS Bulletin A, coded as usno or usnd) is specified in process.defaults or the sh_gamit command line and implemented via the link in the project tables/ directory.
For the non-tidal atmospheric loading (otl.grid) and the atmospheric delay (map.grid) files the link in the project tables/ directory is made to a ~/gg/tables/ version for the appropriate year.
The grid files for VMF1, atmospheric tidal loading, and non-tidal atmospheric loading may not be needed for most analyses, so their links can remain empty (see below for sestbl. entries).
All of these global tables need to be updated from time to time—the EOP and the VMF1 and ATML grid files daily or weekly if you are processing in near real-time;
dcb.dat monthly;
leap.sec yearly;
svnav.dat whenever a new satellite is launched;
and the receiver/antenna tables whenever new instrumentation appears.
Note that with the 10.7 release the Earth and Sun positions are obtained from a 20-year tabulation, file named nbody which may be linked in ~/gg/tables/ either to the MIT/CfA file nbody740.2020.asc used in the past to produce soltab. and luntab. for each year or to the JPL file JPL.DE200, which is the IGS standard.
We’ve found no significant difference in GPS orbital accuracy between the two ephemerides and hence have created the link in ~/gg/tables/ to the MIT/CfA file for continuity.
Nutation, which were tabulated in nutabl. for each year from an IERS-produced subroutine, are now computed internally from the subroutine.
If the nbody link is empty, GAMIT will revert to using soltab.<yyyy>, luntab.<yyyy>, and nutabl.<yyyy> which are available through 2018 but will not be created in the future.
The command files (process.defaults, sites.defaults, sestbl., sittbl., autcln.cmd, and the GLOBK files) are usually specific to a particular survey or processing effort, so the main version of these is usually kept in the project tables/ directory or a higher-level directory common to multiple projects, each of which may pertain only to a single year’s data.
(It is possible to include multiple years within a single project by pre-pending the year to the day directories, but this introduces complications in linking single-year, meteorological, and loading files into the project tables/ directory.)
When sh_gamit runs it will link these files into each day directory.
However, if a file by the same name already exists in the day directory, it will not be removed, so if you need to have a different setting for one day (e.g. a day-specific autcln.cmd file), you can create it within the day directory and it will be maintained through repeated processing of that day.
The third set of files comprises those that are day-specific.
These include the data files shown at the beginning of this section, but also the orbit, clock, and coordinate files created during the processing.
The primary orbital information for GAMIT is the (short, ascii) g-file (e.g., gigg0.034 where the f for final in the -orbt option has been replaced by g to indicate GPS), which contains for each satellite the values of position and velocity at a particular epoch (usually 12:00 on the day being processed) and coefficients of the 9-component solar radiation-pressure model.
These 16 parameters are sufficient for arc to generate a tabular ephemeris (binary t-file, e.g., tigsg0.034) for model to use in computing the theoretical value of the observations.
In normal processing, the g-file is created by sh_gamit (invoking sh_sp3fit) in the igs/ directory by fitting arc’s model to an ascii tabular ephemeris (in the IGS SP3 format) from an external source.
sh_gamit then copies the g-file to the gfiles/ directory and creates a link from the day directory to the file in gfiles/.
This complicated procedure is useful for two reasons:
1) GAMIT requires partial derivatives of the orbital position with respect to the initial parameters in order to estimate these parameters, and these are not available on the SP3 file;
2) the igs/ and/or gfiles/ directories can be used to create multiday orbits for processing pre-IGS data.
The satellite clock file (e.g., jcodr0.034 or jbrdc0.034) and receiver clock files (e.g., kblyt0.034, iscal0.034) all exist solely within the day directory.
A description of each of these files may be found in Chapters 1 and 2 of the GAMIT Reference Manual.
The main coordinate file for the survey is named lfile. and kept in the project tables/ directory.
When sh_gamit runs it makes a day-specific link, e.g. lscal0.034 within each day directory, where updates are made by after each of the two solutions and given the names, e.g., lscala.034 and lscalb.034.
We discuss in Section 3.2 the rules for updating ../tables/lfile..