CDAAC
  Home Page     Data Center     Research Tools     Post Process Results     Climate Processing  
  Data Access     Data Download Interface     File Formats     Documentation  


Name Template: PUB/MISSION/config/fidPre/fidPre_YYYY.DDD.AAA_scs

AAAduration (days)
DDDDay of year
MISSIONMission ID (eight characters or less--champ, champrt, sacc, sacctst, etc)
PUBBase directory for the pub hierarchy
YYYYYear

This table stores location and other information about fiducial data sites. The table is in the 'SCS' format used with the Bernese software by the UNAVCO Japan project. The format of this table is due to Jim Johnson, UCAR/GST/COSMIC. The fidPre files store precise position information for a specific date range, whereas the fidTab file stores a-priori, approximate positions used to start the position estimation process.
The file will contain at least one record for each site as follows:

% OHI              950229 ITRF94     1998.0000000 OHIO
  WIN 1996 001.0000000 50083.0000000 1998 001.9999884 50814.9999884
  CRD    -3941010.5940     3406280.6137     3668441.9816    0.2    0.2    0.2
  VEL          -0.0023           0.0008          -0.0032    0.2    0.2    0.2

DESCRIPTION OF FILE:

General:  Each record will start with the % character.  Each field in
the record will follow this character separated by one or more blanks
and/or return characters.  Each label such as WIN is a required field.
The format for the numbers can either be floating point or scientific
notation.  The fields of the record should be broken up into lines as
in the above example to improve the readability of the file.

Why the '%'?

This is so the files can be parsed easily with awk, for example:

#!/bin/sh
#
# reformat SCS file with awk
#
cat << _EOF_ > tmp$$.awk
BEGIN{RS="%"}
{printf("%-16s %10.4f %10.4f %14.4f %14.4f %14.4f %7.4f %7.4f %7.4f\n",
        \$1,\$8,\$11,\$13,\$14,\$15,\$20,\$21,\$22);}
_EOF_
#
# since records start with %, there is one extra record
# separator (as far as awk is concerned) so we need to 
# toss the first line with tail +2
#
awk -f tmp$$.awk < $1.scs | tail +2 > $1.my_format
rm -f tmp$$.awk



Fields:  Each field description is preceded with its position in []
brackets.

[01] Long station name
        [02] DOMES number of station
        [03] Reference frame for coordinates
        [04] Epoch for coordinate (note 1)
        [05] Four character station name -- This is the primary identifier 
             of fiducial stations for COSMIC.

[06] WIN (note 2)
        [07] Year [08] Day of year [09] Modified Julian day (Start time)
        [10] Year [11] Day of year [12] Modified Julian day (End time)

[13] CRD
        [14] X Coordinate in meters
        [15] Y Coordinate in meters
        [16] Z Coordinate in meters
        [17] X Coordinate sigma in millimeters
        [18] Y Coordinate sigma in millimeters
        [19] Z Coordinate sigma in millimeters

[20] VEL (note 1)
        [21] X Velocity in meters/year
        [22] Y Velocity in meters/year
        [23] Z Velocity in meters/year
        [24] X Velocity sigma in mm/year
        [25] Y Velocity sigma in mm/year
        [26] Z Velocity sigma in mm/year

Note 1:  The epoch in field [04] is used with the velocity in fields [21]
-[26] to get the coordinate of the site at a desired time.  The position
at a give point it time is:

        Xe1 = X + (e1 - e)vX
        Ye1 = Y + (e1 - e)vY
        Ze1 = Z + (e1 - e)vZ

Where:
Xe1, Ye1, Ze1   Coordinates at time e1
X, Y, Z         Coordinates from fields [14] - [16]
vX, vY, vZ      Velocity from fields [21] - [23]
e               Epoch given in field [04]
e1              Epoch we want coordinates for

Note 2: This time window should indicates the time period for which the
coordinates and velocities are guaranteed to be valid.  The values can
be used for times outside of this window with the understanding that
they may be incorrect if the site experiences an event in the mean time.

In the fiducial table, each site could have more than one record with
non-overlapping time windows, for example:

% USAMI            92106  ITRF94     1998.0000000 USAM
  WIN 1996 001.0000000 50083.0000000 1997 062.9999884 50510.9999884
  CRD    -3952066.4941     3425564.6752     3638524.5842    0.9    0.9    0.8
  VEL          -0.0023           0.0037          -0.0059    0.8    0.7    0.7
% USAMI            92106  ITRF94     1998.0000000 USAM
  WIN 1997 063.0000000 50511.0000000 1998 001.9999884 50814.9999884
  CRD    -3952066.5099     3425564.6656     3638524.5751    0.4    0.4    0.4
  VEL           0.0007           0.0055          -0.0044    0.7    0.8    0.8

The correct record to use would be determined by
these rules:

(1) If the request time is within the time window of a record, return
that record.

(2) If the request time is after the end time of the latest time window,
return the latest possible record.  Conversely if the request time is
before the start time of the earliest record, return the earliest record.

(3) If the request time is in between time windows, return the record
that is closest in time.

Condition (3) should not happen -- coordinates should be estimated
contiguously.  I can think of a few possible exceptions, such as a site
being disabled and then moved to a new location (a new antenna perhaps).