|
|
Guide to GPS processing under gp
W. H. Prescott
Last update of text: 1997 May 02
(Listings updated more frequently)
Table of Contents
Introduction
gp is a set of Unix scripts and programs for processing Global Positioning
System (GPS) data. The system is designed to handle both "continuous"
and "campaign" style GPS observations with a minimum of operator
effort. The system is implemented on a Unix platform. The actual processing
is carried out with the GIPSY software
(E-mail to GIPSY).
gp is an interface to GIPSY.
This manual assumes some familiarity with GIPSY processing and with the
Unix operating system.
We are currently using GIPSY-OASIS II, Release 4. GIPSY is a product of
JPL and inquiries about the use of GIPSY should be directed to them. We
run the software on a SUN Sparc 10, Model 712 under the Solaris 2.4 operating
system.
The automatic processing carries out the following steps:
- Retrieve data from various internal and external archives
- Retrieve IGS orbits
- Clean data
- Process with GIPSY (IGS orbits, fiducial-free, ambiguities resolved).
- Store results and intermediate processing info on archive.
- Update directory of archive contents.
- Transform results into ITRF94.
- Compute vectors for all stations.
- Update plot and data archives of all previous results for each vector.
- Move plots and data to a public WWW area.
- Update the WWW page listing the available stations.
(Table of Contents)
Running solutions I
In order to initiate gp processing the operator needs to specify
two things: The stations to be processed and the date to be processed.
Specifying the stations:
Create a file (named CampaignsToProcess) containing a list of
the campaigns you want to include in each solution.
e.g.
CampaignsToProcess
------------------
Alaska
Track
See Behind the scenes for details on
how the processing determines which stations to include.
Specifying the date: Command line method:
Execute the command
gp.queue 19950522
All processing is done in daily batches, however several days can be initiated
at the same time. They will be processed one at a time. To initiate processing
for several days:
List all the dates on the command line
e.g.
gp.queue 19950522 19950523 19950524"
Specifying the date: "DatesToRun" method:
Create a file called "DatesToRun" including all the desired dates:
e.g.
DatesToRun
----------
19950522
19950523
19950524
Then execute the command:
gp.queue
(Table of Contents)
Viewing results
Graphical and digital
versions of the results are written to a series of World Wide Web (WWW)
pages. Currently these are stored on
http://quake.wr.usgs.gov/QUAKES/geodetic/GPS
The plots are time histories of the change in position of one station relative
to a second station. For each station pair the plot file contains a
plot for the length, north, east and up components of the vector connecting
the two stations. The data files contain the same information in
digital format. (See the file formats at the end of
Behind the scenes).
(Table of Contents)
Checking the solution
At the conclusion of processing there should be a file named yyyymmdd.log
for each day that was run where yyyymmdd is the day that was processed
(e.g. 19960525). In addition there will be a subdirectory named
yyyymmdd for each day that failed to complete normally. Upon normal completion
the day subdirectory contents are put away and the directory is deleted.
The day log file is also put away automatically and can be deleted when
it is not needed for handy reference.
- Look at plots and data on the Web pages;
- Check the day log files (yyyymmdd.log in the directory you started in).
See that CLEAN/NINJA ran normally. The number of output epochs should be
about 10% of input epochs.
- Log file should start with:
"gp.driver: Processing started:"
and end with:
"gp.driver: Finished Thu Dec 7 23:23:11 PST 1995" (for example)
If the words "stopped" or "terminated" appear, the job
ended abnormally.
- Check to see that day directories disappeared. If so, the script thought
the job was successful.
- In day directory (if still there) vi GetLog to see what remote stations
were available. You should have at least 4 of the following 6 stations:
algo, dra0, fair, gold, kokb, yell. You can also check this in the day log
file. The available tracking stations will be listed under: "Converting
_z to .Z for UNIX uncompress"
(Table of Contents)
Running solutions II
There are actually two ways to run solutions with gp:
gp.queue is designed for running multiple
days with default options. The user has no way to control the options. For
each day, gp.queue creates a day directory,
changes to that directory, calls gp.driver;
and then deletes the day directory when gp.driver
is finished.
In contrast gp.driver is designed to run
a single day and allows a number of options. gp.driver
operates entirely within the working directory of the process that calls
it. The most commonly used gp.driver options
are -d to set the date and -r ("rerun"). "gp.driver -r"
looks for existing qm files and runs a solution for all qm files that it
finds. It skips entirely the data retrieval and gp.clean
steps.
Other options allow control of the decimation interval, the number of iterations
through the cycle slip and outlier detection loops, whether fiducials are
fixed, and some others. Note: Not all options are functioning at this time.
For a complete list of options, execute the command "gp.driver -H"
or "gp.driver -help". Alternatively, the user can look at the
procedure gp.CommandLine which handles
command line processing.
gp.driver has three ways of determining the
status of its various flags and switches. Listed in priority order these
are:
Command line options
Contents of ProcessFlags and SaveObsDate
Defaults stored in gp.CommandLine
With each run, gp.driver writes or rewrites
a file called "ProcessFlags" containing the current values of
all switches. All command line options override any previous values stored
in an old ProcessFlags. For flags not specified on the command line, gp.driver
looks for a existing ProcessFlags file and reads the values from it. If
gp.driver fails to find a ProcessFlags file,
it uses default values for all options not specified on the command line.
A consequence of this is that repeated runs of the same job can be accomplished
simply by executing the unadorned command
gp.driver
Settings from the previous run will be read from ProcessFlags and used.
"SaveObsDate" is a file that stores the date being processed in
a number of required formats. The point of SaveObsDate is that the
creation of this file is the only place where any date manipulation is done.
All the other routines get their date information from this file.
This file is created by CreateObsDateFile called from gp.driver
if the -d yyyymmdd option is included. Without the -d option, gp.driver
looks for an existing SaveObsDate file. If neither a -d option, nor an existing
SaveObsDate file is found, gp.driver terminates
with an error.
The software also looks for a file called "StationsToExclude". If this file
exists, it is read DeleteStations and
qm files for the corresponding stations are deleted.
(Table of Contents)
Post Processing
The end product of the processing up to this point is a file (stacov)
containing X-Y-Z coordinates of all stations in the solutions
in a non-fiducial reference frame (i.e. in no reference frame).
The non-fiducial stacov file is the end product of the "operational"
processing. From that point on, the processing is experimental,
and subject to frequent revision. The following is a description of the
post-processing currently (1997/04/15) in use.
gp.results controls the post processing.
The non-fiducial stacov file is transformed into a reference frame
by applying a 7 parameter Helmert Transformation. The current reference
frame is ITRF94 which is by design consistent with the NUVEL-NNR1A
plate motion model.
Parameters of the Helmert transformation are chosen (by the
GIPSY routine transform) to minimize the misfit at a selected set of
stations (referred to for convenience as "reference" stations).
The reference stations generally include:
ALBH, ALGO, DRAO, FAIR, GOLD, KOKB, NLIB, PIE1,
RCM5, WES2 and YELL
In addition, the reference stations may include some
subset of the local stations.
After transforming the positions into the reference framework,
the X-Y-Z positions of the stations are saved
(gp.UpdateXYZ) in
/attic/GPSdata/postprocess/xyz
Residuals to the transformation process are saved
(gp.UpdateRes) in
/attic/GPSdata/postprocess/res
gp.results
then calls gp.www.NEU
which looks at each station included in current campaigns.
For each, gp.www.NEU:
Steps to obtain a "final" solution for a net:
- Delete the file /attic/GPSdata/postprocess/itrf/NetName/gp.stacov
- Create a list of stacovs for NetName
(grep NetName /attic/SolutionList > Stacovs.NetName)
- Create new xyz files (RebuildXYZFiles -s Stacovs.NetName)
- Generate new reference stacov files for the net (gp.www.NEU NetName)
- In the directory /attic/GPSdata/postprocess/NetName, change
itrf94.xxxx.stacov.0 filenames to itrf94.xxxx.stacov for all stations
with "good" positions and velocities (RenameITRFStacov0 &
RenameITRFStacovX are useful for this)
- In same directory, run MergeITRFStacovs to generate gp.stacov
- Recreate the xyz files (RebuildXYZFiles -n -s Stacovs.NetName -c NetName)
using only the local stations.
- Run gp.www.NEU NetName to regenerate plots
Note: About RebuildXYZFiles options:
-n option suppresses inclusion of the "tracking" gp.stacov file
-s option specifies the file containing the list of stacovs to be
used in rebuilding the xyz files
-c option specifies which gp.stacov files to use. Program always
looks for those that are part of the stacov filename. In addition it adds
those specified on the -c option.
(Table of Contents)
Reference Frames
During post-processing the non-fiducial solution is transformed
into some "reference frame". This reference frame is defined
as follows. The base for it is the collection of positions
and velocities in the file:
/attic/GPSdata/postprocess/itrf/itrf94/gp.stacov
To this, the software adds any positions and velocities
found in files with the name
/attic/GPSdata/postprocess/itrf/xxx/gp.stacov
where xxx is one of the campaigns being processed.
itrf94/gp.stacov is always present. The others
may or may not be available.
The xxx/gp.stacov files are built from xxx/itrf94.yyyy.stacov.n
files written by
CommonMode, where xxx is the campaign, yyyy is the station,
and n is a integer indicating the segment (0, unless there is an
entry in the
/attic/GPSdata/postprocess/offsets directory for this station, in which
case there will be multiple files for the station).
When campaign xxx is processed by
CommonMode, a file is written for each yyy station.
It is then necessary for the user to review these files. Those that
have reliable positions and velocities are renamed from
xxx/itrf94.yyyy.stacov.n to xxx/itrf94.yyyy.stacov.
Then MergeITRFStacovs
is run in the xxx directory to produce a gp.stacov from all the
itrf94.yyyy.stacov files.
(Table of Contents)
Behind the scenes
The following paragraphs provide a brief summary of the processing carried
out by gp. For details, the scripts themselves should be consulted.
(Note: The script listings can be automatically updated with gp.UpdateManual
and consequently are likely to stay more current than this discussion.)
Processing is initiated with either gp.queue
or gp.driver. gp.queue
checks to insure that adequate disk space exists, then sequentially initiates
processing for each of the dates supplied to it (on the command line or
in DatesToRun). For each date, gp.queue creates
a day directory named yyyymmdd, changes to that directory and calls
gp.driver with a -d yyyymmdd option, directing all of the
output to the file, yyyymmdd.log. Upon return from gp.driver,
gp.queue either calls gp.SaveLogFile
to delete the day directory (if the run was successful) or calls gp.DeleteDebris
to delete the large .nio files (if the run failed for any reason). gp.driver
can also be executed directly, in which case other options are available
(see the source for gp.CommandLine or execute gp.driver -h).
gp.driver first calls gp.CommandLine
which reads and/or creates a ProcessFlags file and then stores the
options specified on the command line. Command line options take precedence
over flags in the process flags file and gp.CommandLine
will overwrite any existing flags in the ProcessFlags file with the
current values from the command line. Command line options include: setting
the decimation interval; toggling between fiducial free (the default) and
fiducial fixed solutions; requesting a rerun (which uses existing qm files),
and others. For a complete discussion type gp.driver -h or consult
the gp.CommandLine script.
gp.driver controlls all the real work in
the processing. It carries out six main activities, each done by a separate
subroutine:
gp.data retrieves rinex data and igs orbit
data. It looks first in the local archive. If the data are not found in
the local archive, and if the stations are labeled remote in the
CampaignList, then the script looks for the data on remote archives (CDDIS,
TOBA, and BODHI). (Since we save local copies of remote data that we have
used in the past, stations labeled remote may be found locally.) gp.data
renames the rinex files in the GIPSY preferred JPL format. The rinex files
are cleaned and decimated with GIPSY programs, ninja, clockprep,
and/or phaseedit producing individual .qm files. IGS orbits
in sp3 format are converted to ECI format. Note that
gp.data
processing is skipped when the -r option is selected in gp.driver.
The rinex and igs orbit files are stored to the local archive (with local
naming conventions). gp.data automatically
updates the GIPSY files, sta_pos, sta_svec, and sta_id.
Between the gp.data and gp.solve
steps, gp.driver merges the individual qm
files into a single qmfile.
gp.solve is pretty much standard GIPSY processing.
It calls in sequence, qregres, preprefilter, prefilter, filter, smapper,
postfit, and postbreak. This loop is repeated until postbreak
finds no new cycle slips, or until a loop limit is reached. The default
loop limit is 5 iterations, which has thus far been adequate for most cases.
The loop limit can be specifed with an option (-sl) on the call to
gp.driver. If more than 200 new cycle slips
are found on any iteration, the program exits with an error.
gp.edit looks for outliers in the postfit.nio
file, removes existing outliers, calls smapper, and then repeats
until no outliers remain, or until a loop limit is reached. The default
loop limit is 5 iterations, which has thus far been adequate for most cases.
The loop limit can be specifed with an option (-el) on the call to
gp.driver. If more than 200 outliers are
found on any iteration, the program exits with an error.
Between the gp.edit and gp.amb steps,
gp.driver splits the single qmfile
into individual qm files.
Once all outliers have been removed, gp.amb
is called to fix the integer ambiguities. gp.amb
calls the GIPSY routines, amb_nml, ambigon2, and smapper.
gp.results runs several GIPSY routines to
generate and manipulate the solution. First it generates a .stacov file
with the GIPSY routine stacov. If sufficient (>4) tracking stations
are present, gp.results calculates the vectors
between all the pairs of stations in the current solution, and adds a record
to the appropriate LNEV file. These vectors (LNEV) are added to a cumulative
time-tagged file (.lnev) of all vectors for the station pair. The original
.lnev file is stored on /attic, a local archive.
gp.results saves the names of the campaigns
in a file called /attic/CampaignsToWeb. Under the control of a cron file,
gp.www is run daily.
gp.www then generates
plots of the entire lnev files, and a copy of the .lnev file and the .gif
file are copied to a Web server (http://quake.wr.usgs.gov/QUAKES/geodetic/GPS).
Plotting is done with GMT. Ghostscript is used to convert the .ps output
from GMT to a .gif file.
The last major activity of gp.driver is to
save the results and some of the intermediate files to the local archive.
gp.save keeps the qm files, the log files,
the postfit.nio file and the stacov file.
gp.save is the last step in the processing.
After calling gp.save, gp.driver
terminates. If the processing had been initiated by gp.driver,
processing stops. If processing has been initiated by gp.queue,
contol returns control to gp.queue. At this
point gp.queue, changes from the day directory
to its original working directory, copies the yyyymmdd.log file to this
working directory and either deletes the day directory or deletes large
files from it. The former, if processing terminated normally, and the latter
of it did not. Then gp.queue goes on to process
any other days requested.
About error termination
The scripts attempt to trap errors and pass them up the chain of calls so
that the log file will contain a sequence of abnormal termination messages.
Three scripts use an error exit status code to signal a normal (but perhaps
undesirable state). For all others, a non-zero exit status is an indicator
that something unexpected went wrong and will trigger a chain of error exit
messages. The three exceptions are: gp.CheckForOutliers,
gp.CheckForNewSlips, and gp.CountTrack.
Miscellaneous comments on the processing:
- All working files generated by the processing are stored in a subdirectory
of the starting directory named yyyymmdd.
- During each run, cleaned copies of the individual qmfiles writeover
the starting qmfiles.
- Processing terminates if there are more than 200 cycle slips or more
than 200 outliers.
- LNEV files are updated if there four or more tracking stations
included.
- The scripts read CampaignsToInclude, and generate a listing (GetLog)
of all the stations to be processed. Examination of GetLog is a quick
way to see what stations were requested, and for which stations the script
found data (marked "have").
- The script looks first for rinex files on the local archive (/attic/...).
- If stations are labeled "remote" in GetLog, the script looks
for their data on various external archives:
cddis.gsfc.nasa.gov/GPS1:[GPSDATA.YYdoy.YYN]
cddis.gsfc.nasa.gov/GPS2:[GPSDATA.YYdoy.YYN]
toba.ucsd.edu/rinex/YYdata/doy
bodhi.jpl.nasa.gov/pub/rinex/doy_
- Processing results stored on the local archive (/attic/...) are tagged
with a prefix derived from the Campaigns processed (Consequently it is possible
to have multiple solutions for a given day, although they would have to
be generated separately). _
- The stacov file is Helmert transformed to agree with ITRF94 coordinates
at some subset of ALBH, ALGO, DRAO, FAIR, GOLD, KOKB, NLIB, PIE1,
RCM5, WES2 and YELL (See Post Processing
for more detail).
In addition to various GIPSY standard files (e.g. sta_pos), gp uses a number
of specially named files:
Stored in the working directory:
Stored in the archive:
- /attic/CampaignList contains a list of campaigns and their member
four-character codes.
- /attic/NameTrans contains a translation table converting various
name forms into a standard set of four-character codes.
- /attic/DataList contains a listing of the raw, rinex and solution
files in the /attic archive. It is automatically updated during the gp
processing.
- /attic/StationList contains a listing of the four-character codes,
the expanded name and, sometimes, the coordinates.
The archive /attic/GPSdata contains all of the observation dependent
files associated with GPS data:
- /attic/GPSdata/solutions/lnev - a collection of files
containing vector components as a function of time
for all station pairs. (Obsolete - replaced by xyz files).
- /attic/GPSdata/postprocess/xyz - a collection of files
containing vector components as a function of time
for all stations.
- /attic/GPSdata/postprocess/res - a collection of files
containing residuals to the helmert transformation from
non-fiducial stacov file to ITRF xyz file.
- /attic/GPSdata/postprocess/offsets - a collection of files
containing times at which there is a discontinuity in the time series.
- /attic/GPSdata/postprocess/badpts - a collection of files
indicating known outliers
(CommonMode
ignores these points for most purposes).
- /attic/GPSdata/postprocess/itrf - a collection of directories,
one for each campaign, containing reference stacov files.
- /attic/GPSdata/raw - all of the online raw GPS data files.
- /attic/GPSdata/rinex - all of the online rinex GPS data files.
- /attic/GPSdata/intermediate - Various files produced in the processing
(log files, qm files, postfit.nio).
- /attic/GPSdata/solutions - Files containing the final coordinates
and their variance-covariances (GIPSY stacov, GAMIT h-files, and Bernese
output files).
CampaignsToInclude
------------------
Bard
Track
DatesToRun
----------
Bard
Track
DataList (Tab delimited)
------------------------
DayID Code SessID Sta HI StartDate StartTime DOY EndDate EndTime Raw Rinex Solution Interval EQHRs RecTyp Firmware Software Latitude Longitude Comment
19950821 brib a Briones 0.0000 95/08/21 00:00 233 95/08/21 23:59 bbriba95.233 brib19950821ao bard.95aug21.stacov.fixed 30 n/a ASHTECH Z-XII3 1C01 Gipsy n/a n/a n/a
19950821 carr a CarrPGGA 0.588000 95/08/21 00:00 233 95/08/21 23:59 n/a carr19950821ao bard.95aug21.stacov.fixed 30 n/a ROGUE SNR-8000 95.03.08 Gipsy n/a n/a n/a
19950821 casa a CasaTrk 0.163000 95/08/21 00:00 233 95/08/21 23:59 n/a casa19950821ao bard.95aug21.stacov.fixed 30 n/a ROGUE SNR-8000 95.03.08 Gipsy n/a n/a n/a
19950821 chab a ChabBARD 0.0020 95/08/21 00:00 233 95/08/21 23:59 bchaba95.233 chab19950821ao bard.95aug21.stacov.fixed 30 n/a ASHTECH Z-XII3 1E00 Gipsy n/a n/a n/a
StationList (Tab delimited)
---------------------------
brib Briones Not_Available -2681173.031 -4265460.548 3898551.895 0 0 0 NA
bric Brick Brick_1949_USCGS -2288107.5 -4562251.636 3814615.711 NA NA NA 8-Jul-93
brin Brink2 Brink_2_1967_USC&GS -2414401.527 -4710204.124 3548085.63 NA NA NA 25-Dec-94
brot Brothers Brothers_1989_GPS_ORDOT -2347121.849 -3968720.271 4394153.909 0 0 0 4-Dec-94
bru2 Brush2 Brush_2_1978_NGS -2699876.163 -4359072.661 3781086.928 NA NA NA 25-Dec-94
brwn Brown Brown_5131_VA1913_USGS -2356463.863 -4621509.768 3700883.495 0 0 0 18-Mar-94
CampaignList (Tab delimited)
----------------------------
Alaska 1zzz local
Alaska 4224 local
Alaska ahki local
Alaska alik local
Alaska augu local
Bard brib local
Bard carr remote
Bard casa remote
Track algo remote
Track drao remote
Track fair remote
Track gold remote
Track kokb remote
Track yell remote
"local" tells the script that the data only exist on local
archives.
"remote" means it can be on either local or remote archives.
Sample LNEV Contents:
---------------------
ALGOBRIB 95jul16 95 197 95.5394 3660821.1508 0.0023 130224.5791 0.0013 -3504916.9490 0.0026 -1048909.0700 0.0028
ALGOBRIB 95jul21 95 202 95.5530 3660821.1483 0.0027 130224.5762 0.0013 -3504916.9386 0.0030 -1048909.0966 0.0048
ALGOBRIB 95jul30 95 211 95.5777 3660821.1427 0.0026 130224.5641 0.0012 -3504916.9335 0.0029 -1048909.0957 0.0046
The fields are Station 1/Station 2, Date, Year, Day Number, Decimal Year,
Length, Standard Deviation of Length, North, Std. Dev. of North, East, Std. Dev. of East, and Vertical, Std. Dev. of Vertical.
(Table of Contents)
Portability
This manual describes the system as it is implemented at the U.S. Geological
Survey in Menlo Park, California. To implement the processing on another
system, several steps would be required:
- Setting up the various files and directories required;
- Modifying some of the scripts to point to different places;
- Modifying some of the scripts to deal with different naming conventions.
We keep all of the local source code (as distinguished from scripts and
programs distributed with GIPSY) in a directory called /goa/local.
Most gp scripts are found in /goa/local/gp_dir, but gp
also calls some scripts in /goa/local/util_dir, /goa/local/get_dir,
and probably some others. in addition to the templates distributed with
GIPSY, the scripts make use of some local templates stored in /goa/local/templates.
All of the procedures in gp are written in csh or perl. (The underlying
GIPSY programs are written in csh, perl and fortran.)
Porting the software will require creation of a set of specially named files:
CampaignList, DataList, StationList, NameTrans.
See the section (Behind the scenes)
for a brief discussion of some of these files.
(Table of Contents)
Manual sources
This manual can currently be found at:
http://quake.wr.usgs.gov/QUAKES/geodetic/gp.manual.html
(Table of Contents)
Backup Tape Info
Instructions for restoring from backup tapes.
LOG ON AS SUPERUSER OR THIS WON'T WORK !!!!
# cd /cellar1 (for example. Pick a place with lots of space)
# ufsrestore i
ufsrestore > add ./DataList
ufsrestore > ls
.:
.gmtcommands bard2/
19951124/ bard3/
19951124.log bard_bad/
BS3_gp_solution_files/ bard_good/
CampaignList bard_output/
CampaignsToWeb bin/
*DataList geoddata/
DataList.postRename lib/
DataList.preRename lost+found/
GPSdata/ mac/
StationList mapdata/
StationList% orbitdata/
StationList.old rinex_trans/
TableOfGoodBardSolutions vax_source/
Testwp2.dir/ welcome.msg
bard/
ufsrestore > extract
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
ufsrestore >
------------------------------------------------------
------------------------------------------------------
------------------------------------------------------
To restore from a backup tape that has more than one backup set
on it, for example, from a tape with /cellar1 and /cellar2, and you
want something from /cellar2, do this to skip past the cellar1 backup:
picard-m !? ufsrestore ifs /dev/rmt/0hn 2 <-- THIS SKIPS TO THE 2nd BACKUP SET
ufsrestore > ls
.:
CampaignList DataList NameTrans StationList
Closet_dump_logs/ GPSdata/ SolutionList restoresymtable
ufsrestore > ls GPSdata/rinex/1992
./GPSdata/rinex/1992:
9201/ 9203/ 9205/ 9207/ 9209/ 9211/
9202/ 9204/ 9206/ 9208/ 9210/ 9212/
ufsrestore > add GPSdata/rinex/1992/9210
ufsrestore > ls
.:
CampaignList DataList NameTrans StationList
Closet_dump_logs/ *GPSdata/ SolutionList restoresymtable
ufsrestore > extract
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
ufsrestore > quit
------------------------------------------------------
------------------------------------------------------
------------------------------------------------------
To restore all of the files on the GPSdata raid array:
hayford-m !? ufsrestore ifs /dev/rmt/0hn 7 <-- This skips to the 7th backup set,
ufsrestore > ls the one for GPSdata
.:
backups/ inc_dump.Attic.990201
bin/ intermediate/
full_dump.Attic.990203 level3_dump.Attic.990202
full_dump.Slash.990129 lost+found/
full_dump.Slash.990201 postprocess/
full_dump.Slash.990202 raw/
full_dump.Slash.990203 rinex/
inc_dump.Attic.990129 solutions/
ufsrestore > add raw
ufsrestore > add backups
ufsrestore > add bin
ufsrestore > add full*
ufsrestore > add inc*
ufsrestore > add lev*
ufsrestore > add pos*
ufsrestore > add intermediate
ufsrestore > add rinex
ufsrestore > add solutions
ufsrestore > ls
.:
*backups/ *inc_dump.Attic.990201
*bin/ *intermediate/
*full_dump.Attic.990203 *level3_dump.Attic.990202
*full_dump.Slash.990129 lost+found/
*full_dump.Slash.990201 *postprocess/
*full_dump.Slash.990202 *raw/
*full_dump.Slash.990203 *rinex/
*inc_dump.Attic.990129 *solutions/
ufsrestore > extract
You have not read any volumes yet.
Unless you know which volume your file(s) are on you should start
with the last volume and work towards the first.
Specify next volume #: 1
set owner/mode for '.'? [yn] y
ufsrestore > quit
(Table of Contents)
Contact the author
Send comments or questions to:
wprescott@isdmnl.wr.usgs.gov
(Table of Contents)
Procedures
Alphabetical Procedure List
(Table of Contents)
Logical Procedure List
(Table of Contents)
Web page by:w
Will Prescott
Procedure lists and source code last updated:
2002/02/13-19:05:05
| |
