Contact a Training Representative
1.Creating A Work Area
2.Downloading GPS Data
3.Downloading an Ephemeris
4.Selecting Sites To Hold Fixed
5.Creating The POM Files
6.Running run_survey
7.Manually Modifying The Processing


Everything is now in place to process these data. run_survey can be run from any location on the system because command-line arguments uniquely identify the directory to be processed. The required command-line arguments are, in this order:
  1. base of the processing directory tree
  2. the year of the data files (and part of the work directory name)
  3. the doy of the data files (and part of the work directory name)
Other command-line arguments are recognized and described in the on-line documentation hosted, in part, at NGS.

Recall that the purpose of run_survey is standard, hands-off processing. The run_survey script was designed for batch processing such as initiation by a crontab or a block of several day intiated sequentially by a simple script.


At the end of the last tutorial, the current directory was ~/tutorial/files.

run_survey can be initiated from any location but, because no further actions are required in the files subdirectory, change to the base of the processing tree.

cd ..
Start run_survey. Recall that the assumption in this tutorial that the processing directory tree was created in the users home directory. If this not the case, make the appropriate substitution. The dates and times shown here will, of course, be different.
  run_survey ~/tutorial 01 033
  run_survey WARNING: "editdb.par" not found.
  run_survey WARNING: Using default parameters coded in editdb.
  run_survey: PROCESSING /home/mark/tutorial/01_033          @ 01/03/08 12:56:19
  run_survey: UNCOMPRESSING RINEX FILES                      @ 01/03/08 12:56:19
  run_survey: CREATING elv.plt USING mergedb                 @ 01/03/08 12:56:20
  run_survey: DESIGNING NETWORK USING stree                  @ 01/03/08 12:56:26
  run_survey: CREATING EDITTED, TWO STATION DATABASES        @ 01/03/08 12:56:26
  run_survey:   gode + usna -> aaac                          @ 01/03/08 12:56:26
  run_survey:   gode + sol1 -> aaab                          @ 01/03/08 12:56:33
  run_survey: BASELINE ESTIMATION USING pages                @ 01/03/08 12:56:40
  run_survey: NORMAL TERMINATION                             @ 01/03/08 12:57:13


Messages from run_survey which appear on the screen are also stored in the run_msg file in the work directory. The run_msg file is particularly valuable in tracking multiple batch jobs.

The warnings shown are literally that, warning that something may not be optimal but the processing can and will continue.  If processing were to continue with other data and other projects, files common to all projects, like the site info or ant info files could be stored in a common location.  In this example, that location is the directory "/opt/GPS/info" and that location has been hardcoded into run_survey so that this script will always look there for these common files.  The run_survey script can be modified so that the "CDIR" variable contains the path of this common directory on the user's system.

run_survey attempts to trap all errors and exit gracefully. If and error does occur, a message and time tag are printed to the screen and the run_msg file. The work directory is left in the same state as when the the error occurred. One can then go into the work directory, manually run the indicated program (or script) and begin debugging the fault.

Software development has always kept an eye towards the PC environment. To this end, the eight character name + dot + three character extension file naming convention is generally kept. In turn, the twelve character file name restriction implies that files, which could be identified most clearly by using the four character site ID's, must use a different naming convention. This "renaming" convention is coded into and enforced by the stree program and is for the purpose of file naming only. The convention is best defined by its implimentation.

  1. gode,
  2. sol1,
  3. usna.
  1. gode = aa
  2. sol1 = ab
  3. usna = ac
The site ID's are sorted alphabetically. This tutorial uses three sites:
Each site is then given a two character ID depending upon its position in this alphabetically ordered list: aa = 1, ab = 2, ac = 3, ...; therefore our list becomes:
stree, in identifying baseline pairs of sites, subsequently uses these two character site ID's to name files. For example, files associated with the sol1-gode baseline would contain the string abaa.
One additional note, after stree, the minimum logical data grouping is the two sites which comprise a baseline. Hereafter, these two site, baseline pairs will be referred to by their stree generated four character ID's or ???? generically.
Explicitly knowing this convention is not required. stree lists the baseline pairs with their ID's in its summary file, elv.loc. For convenience, run_survey duplicates this list in the bls file.

The working directory, ~/tutorial/01_033, has be modified. The files and subdirectories will be listed below with brief descriptions of their purpose.

The directory structure now looks like:

The purposes of the three new subdiretories and the files they contain are:

  data holds the original RINEX files and ephemeris.
  inpt holds input and output files from intermediate processing steps:
    ????00.edt are edit instruction generated by editdb,
    bd_???? are bdata input files,
    do_???? are editdb input files,
    eclipse is a list of eclipsing satellites and approximate eclipse times,
    elv.loc is the stree summary file,
    mergedb.sum is the mergedb summary file,
  plts holds plot files. Several file types are used in plotting: the plt and lim files are required, the rest are optional:
    *.plt files contain the values to be plotted,
    *.lim contain plot limits to speed display,
    *.scn contain reference satellite scenario information,
    *.log files are edit instructions created by xplot during manual editting.
    Two plot types created in normal processing (many others are possible):
    ????01pf are post-fit residual plots create by pages,
    elv are satellite elevation angles verses time for each site, created by mergedb.

The work directory, 01_033 in this example, now has the pages processing files (binary files will be explicity identified; all other files are ASCII and, therefore, viewable with an editor):
  ????01.brk lists of times where phase bias estimates will be restarted in pages. In other words, times of known or suspected cycle slips. These files are created by editdb.
  ????01dt.dat binary files of phase and pseudorange values, and edit instructions.
  ????01or.dat binary files of satellite coordinates.
  ????01hd.dat files providing the minimum information needed for further processing.
  a copy of the ephemeris if one has been provided.
  pages.inp the pages input file. This file contains flags controlling free parameter estimation and database informtion; things which would change with each processing session.
  pages.log a run-time log of pages messages and products.
  pages.nrm a binary file created by pages and used by gpscom.
  pages.skl the pages input contain model and constraint controls for things which change infrequently.
  pages.snx the pages summary file in SINEX format.
  pages.sum a complete summary of the pages solution.
  run_msg the run_survey run-time messages mentioned above.
2009-02-15 18:41 UTC