GIPSY Processing at Georgia Tech

Step-by-step:

1. All processing assumes that you are starting with usable RINEX files. Often times one must first correct from various proprietary receiver formats to get to RINEX however. If you are faced with this, I would recommend you look more closely at TEQC for more information.
   
2. The group account needs to be gps
   
3. setup your configuration to see the correct GIPSY6 directories

        % source /usr/local/geophysics/GIPSY/goa/rc_gipsy.sh # gispy specific
        % source /home/gipsy/local_scripts/bin/rc_gipsy6local.sh # GT specific
   

4. Make three files (sta_id, sta_pos, sta_svec) and put them in your home directory. Details of this can be read in the GIPSY manual.
   
   THESE ARE FIXED FORMAT FILES, HENCE THEY HAVE TO MATCH THE BELOW FILES IN FORMAT, CHARACTER BY CHARACTER
   • sta_id: GPS station identification (pretty straight forward)
     One could always try the program rnx2sta_id, but I have never tried this.

     #stat     0 stat (DO NOT ADD THIS COMMENT LINE) 
      ASP1     0 ASP1
      NKM1     0 NKM1
      NKM2     0 NKM2
     

   • sta_pos: Identifies the station position, and its changes in time (change is often not included). Information can usually be pulled directly from the RINEX file. If you do not have the xyz position, you can determine it if you know the geographic coordinates using the proper transformation. I have a program ~anewman/bin/xyz2geod to go the other way. You could always contribute the inverse, or find it online, such as this one from NOAA. Unfortunately, it is in GRS80 instead of WGS84. I don't know how off this will be for a particular envronment--someone could test this with resubmitting this to my xyz2geod program.
     For the start time, it is best to use the first time for which this data is correct. You may want to look at the UNAVCO DAI for this information. I believe log files would de useful here. Make the length of time long enough to cover your data. If I recall, this length is in minutes.
     One could always try the program rnx2sta_pos, but I have never tried this.

     #stat year mo dy hh mn sec   duration      X              Y              Z             dX             dY             dZ
     #                            [days]
     # (DO NOT ADD THESE COMMENT LINES) 
      ASP1 2006 01 01 00 00 00.00 1000001.00    4645947.7352   2201063.7683   3762471.3816  0.00000000e+00 0.00000000e+00 0.00000000e+00
      NKM1 2006 01 01 00 00 00.00 1000001.00    4642407.9934   2203529.1942   3765384.7480  0.00000000e+00 0.00000000e+00 0.00000000e+00
      NKM2 2006 01 01 00 00 00.00 1000001.00    4642467.3645   2205260.4918   3764320.6934  0.00000000e+00 0.00000000e+00 0.00000000e+00
     

   • sta_svec: GPS antenna information for an occupation. Again, use the best start times available. Often, the antenna height information is in header of the RINEX file. Do not default to this unless you have no other data from the logsheets to go by. These are notoriously wrong, particularly if you were to process campaign GPS data. The antenna type is also listed in the header.
     
     
     To get the proper antenna type, look for the antenna information in the rinex file, and correlate this with the appropriate lines in the file ~gipsy/local_scripts/bin/pcenter_bk. Use the antenna field from the first column of this file for the ANT-TYPE below.
     
     One could always try the program rnx2sta_svec, but I have never tried this. After some testing by the students, there are a couple of potential problems with this program. 1st, it only creates a file good for 1 sidreal day. Second, it doesn't seem to put in a good antenna type.
     
     I've written a program called update_sta_svec_from_rinex that will run per file and create line that you can direct into the sta_pos file.
     
     

     #orig new  Starting time          Duration                    Antenna Phase offset      Antenna height from marker
     #stat stat year mo dy hh mn sec   good         ANT-TYPE       X          Y          Z          vert[l]/slant[s]
     # (DO NOT ADD THESE COMMENT LINES) 
      ASP1 ASP1 2010 06 14 00:00:00.00 000345600.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      ASP1 ASP1 2008 05 29 00:00:00.00 000259200.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      ASP1 ASP1 2006 05 13 00:00:00.00 000259200.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      NKM1 NKM1 2010 06 15 00:00:00.00 000259200.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      NKM1 NKM1 2008 05 29 00:00:00.00 000432000.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      NKM1 NKM1 2006 05 13 00:00:00.00 000259200.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      NKM2 NKM2 2010 06 18 00:00:00.00 000259200.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      NKM2 NKM2 2008 05 29 00:00:00.00 000172800.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
      NKM2 NKM2 2006 05 13 00:00:00.00 000259200.00 ATR41249       0.0000     0.0000     0.0000     0.5000 l
     

5. Add Ocean Loading: This will predict the expected mostly vertical deformation the sites would see from normal tidal loading using the current tide models. Using the online servies from the Ocean Loading Webpage, you can input the station XYZ coordinates to create a new ocean loading parameter set for each station. Choose FES2004, and output in vertical and horizontal displacements in BLQ format.
   
   This information will be passed to you in an email, and should be added to your home directory under the name ocnld_coeffs.
6. Download rinex files to your processing folders using get_UNAVCO_files.

    % get_UNAVCO_files 2011 332 334 mozi nomi pkmn # you may have already done this
   

7. For testing, please make a backup copy of the 'YYYY'.'doy' files.

    % cd to ~/GIPSY/RINEX # or whatever directory containing the 'YYYY'.'DOY' rinex files. 
    % mkdir backup
    % cp -a 20??.??? backup/ 
   

8. to run the processing, please go to the GPS data folder and run

   % non-frame.wlpbrun jpl ambi  # (with ambiguity resolved)
   #or
   % # non-frame.wlpbrun jpl  # (without ambiguity resolved -- no need to run this version)
   

9. check the log files see if there are any mistakes.

     % #  cd to 'YYYY'.'doy'/'stat''doy'0.'yy'/
     % cd 2011.245/NKM32450.11
     % cat *.err
   

   If this information is insufficient, you can modify the program ~/GPS_bin/non-frame.wlpbrun to add '-save' to the gd2p_wlpb line. This will keep a *.work file that will retain more information about what is failing. Unfortuantely, not all errors lend themselves well to diagnosis.
10. Once you get a .gd file in your directories, you are ready to create a timeseries file. The results you want is the station coordinate in ITRF2008 reference frame. (.gd files)

     %  mkdir gdfiles
     %  cp  'YYYY.DOY'/*/*.gd gdfiles
    

11. At this point we can make simple timeseries files that will present results in geographic coordinates with independent error for each component.

        % cd gdfiles
        % stat SITE.GD . win3.0
        % # for all files 
        % bash
        %  for file in *.GD
        >    do
        >      stat $file . win3.0
        >    done
    

    Your time series files are in *.GD, figures are in *.GD.ps
    Note that though component-independent errors are reported, the solutions for each component are inherently correlated for any daily solution. As well, the components for data collected at the same time in the same region are similarly correlated. Thus, for careful analysis, it is best to determine component covarience (intercorrelation), as well as inter-station coveriance (sadly, this is rarely done in our field).
12. Next step will be to work with these data to determine either deformation rate or displacement vectors as necessary. This can all be done on our local machines.

    ---