Daily Processing Script Version 1.0

In Summer 2000, fully automated daily processing started using Version 1.0 of the Perl script dailyproc.pl and the control file dailyproc.ctl in connection with the automated procedures Version 3.1 (§4.4.1). Using the UNIX cron utility, the execution of the Perl script was invoked automatically every morning, carrying out all three GAS processing stages. Processing was carried out on a daily basis on data, approximately 30 days back from the current calendar day, allowing extra time for problems in the data flow to be solved prior to processing.

In the first step of the execution of dailyproc.pl, the script reads the processing dependent parameters from the control file and carries out general checks on directory path definitions. The Perl script also checks for all UNIX .now, GAS D and GAS R shell script template files in the directory dailyproctemps, which will be used to create the final shell script for each GAS processing stage using the Perl stream editor, similar to the UNIX sed command used by the automated procedures themselves.

If the GAS pre–processing stage is to be carried out, then dailyproc.pl creates a loop over all stations specified in the control file. This involves creating the preproc.now shell script and the preproc.rprocess from the template files for the specific day to be processed. The GAS D shell script preproc.dates then needs to be modified after each station–specific pre–processing run.

In Version 1.0 of the daily processing script, after the pre–processing stage has been completed for each station, a cleaning report is generated. The Perl script checks for the availability of a cleaned NOTT2 format observation file and if found, reads the σ0 of the residuals for the ionospherically free observable from the associated slip file. If there is no cleaned NOTT2 format observation file for a particular station, then it is investigated whether procarch on workstation monix contains a RINEX format observation file for this station on this day. Depending on the outcome of these checks, a different set of characters are written to the cleaning report file enabling the identification of the problem.

The second part of the quality control occurs after the cycle slip cleaning stage, with the generation of a file for each station holding some statistical information, e.g. the total

Chapter 4. Automated GPS Processing and Analysis 89

theoretical number of days and sessions for which data could have been available, actual numbers of available RINEX and NOTT2 format observation files, total number of cleaned days and sessions, total number of sessions that have not been cleaned, the sum of all σ0, and the average σ0 obtained after the data was cleaned for cycle slips. These files have been denoted as station statistics files.

If specified in the control file dailyproc.ctl, the next stage to be carried out by the Perl script dailyproc.pl, is the GAS network–processing stage. As mentioned above, this involves executing the automated procedures for each sub–network separately. Using Version 1.0 of the dailyproc.pl script, this was performed for a two sub–network configuration. In order to execute the automated procedures for each network, the GAS D shell script netwproc.dates is automatically edited prior to execution.

The next step to be carried out by the daily processing script is the post–processing stage. It was already mentioned that this requires several executions in single network mode in order to post–process each sub–network. After this is completed, all GPS baseline vectors are combined using the network combination mode of the automated procedures. By selecting the post–processing option in the control file dailyproc.ctl, the Perl script uses template files for creating the postproc.now, the postproc.dates and the postproc.rprocess for each sub–network. This involves, stream editing the day to be processed and the number of networks in postproc.now, a list of stations for the baseline definition in postproc.dates and the names and post–processing names for each network in postproc.rprocess. The latter two require modifications after each processing run, as the variables specified are network dependent. Prior to the network combination run of the automated procedures, postproc.now is modified by dailyproc.pl to contain the correct number of sub–networks to be combined, the GAS D shell script postproc.dates is edited to contain a list of all possible stations to be expected by the scripts, and the GAS R shell script is modified with the correct sub–network names, and post–processing name.

Once all runs of the GAS post–processing stage have been completed, a combination report is compiled by the Perl script dailyproc.pl. The first check carried out is on the final CARNET solution file of the combined network adjustment. Then the number

Chapter 4. Automated GPS Processing and Analysis 90

of cleaned NOTT2 format observation files is established and whether at least one file per station is available for the current processing day. Based on this information, the number of stations, which have been used in several sub–networks is known. Now the overall a–posteriori σ0 of the least–squares adjustment process is read from the CARNET summary file. Using the standard errors for each coordinate component of each station listed in this file, the 3–dimensional radial errors for each station can be computed. For stations, which have been used in several sub–networks, the coordinate standard errors of the CARNET solution file of each sub–network are averaged, before the radial error is computed. At this stage, the combination report can be compiled containing the overall a–posteriori σ of the CARNET least–squares adjustment process and the 3–dimensional radial errors for each station. If for any station no radial error was computed, i.e. there was no record for this station in the CARNET solution file, then dailyproc.pl checks for a RINEX format observation file in procarch and depending on the result, a different set of characters is written to the report. Thus by reading this report, it is possible to evaluate, whether a coordinate solution has been obtained for a specific station on a specific day, or whether there was a problem, either due to a missing RINEX format observation file or a computational problem. Using this report together with the cleaning report produced after the GAS pre–processing stage, it is possible to quickly check, whether a dailyproc.pl run for a specific calendar day was successful.

At the end of the post–processing stage, the station statistics files are updated with the new total number of daily coordinate solutions and with the last day for which post– processing has been carried out.

If selected in the control file, the error information of those stations included in several sub–networks can be corrected and final coordinate time series for each station can be produced. To do this, dailyproc.pl first determines which stations have been used in more than one sub–network, by checking the CARNET solution files of the GAS post– processing stage. During this process the associated standard errors for the cartesian and geographic coordinates are obtained from each sub–network and once all CARNET solution files have been read, average coordinate standard errors for each station are computed. These corrected coordinate standard errors are then written to the new final

Chapter 4. Automated GPS Processing and Analysis 91

coordinate time series files. The coordinate standard errors of stations included only once or which have been fixed in the post–processing stage are not modified.

The last step in the Perl script dailyproc.pl is to update the control file with the new date information. If any of the three processing stages or the standard error correction is carried out by the Perl script, then the date of last execution for this stage is incremented by one. This enables dailyproc.pl to determine for which day processing is to be carried out on the next automatic invocation.