Activos que respaldan la Emisión de los Bonos

The automated procedures Version 3.2 are based on automated procedures Version 3.1 described in §4.4.1. They were initially developed by the author in September 2001, when automated processing was split onto several UNIX/Linux workstations. In the period from 1999 to 2001, processing was only carried out on workstation geodix copying the required IGS precise ephemeris and RINEX format observation files from the processing data archives tgarch and, later, procarch (§4.3.1) on workstation ukcogr. With the establishment of the new workstation monix in 2001, the processing data archive procarch was moved from workstation ukcogr to workstation monix.

At this time, the new processing results archive procres was introduced in order to remove the daily processing directories from the project directory. Besides the directories containing the shell scripts, shell functions and template files, the number of daily direc- tories in the project directory had reached well over 1000, making it inefficient. Initially, procreswas created on workstation geodix, but was then moved to workstation monix in order to separate processing from archiving workstations. This configuration was enabled

Chapter 4. Automated GPS Processing and Analysis 77

geodix ukcogr defix

monix Data

Processing

NFS Clients

Processing Data Archive and Processing Results Archive

NFS Server

Figure 4.3: Workstation configuration at the IESSG using automated procedures Ver- sions 3.2 and 3.3 during re–analysis of the UK 25 CGPS station data set in the period 2001/2002.

by running workstation monix as a NFS server, sharing its archive directories with a number of specified NFS client workstations. By configuring workstations geodix, ukcogr and defix as NFS clients, automated GPS processing could be carried out on all three workstations simultaneously. This approach was necessary, as it was decided to re–analyse the complete processing data archive in procarch spanning the period from 1997 to 2002, and extend the CGPS network from 13 to 25 stations. Figure4.3 shows the workstation configuration at the IESSG during the re–analysis of the UK 25 CGPS station data set.

With the creation of the NFS server–client workstation configuration, it was now also possible to establish a directory finalcoords on workstation monix, which contained the final coordinate time series files for different post–processing runs. Each time post– processing was carried out using different process settings, e.g. a reference frame, a di- rectory was created in the project directory on the processing workstation. In order to de–clutter this directory and to have all coordinate time series in one area, the automated procedures Version 3.2 account for these changes.

Chapter 4. Automated GPS Processing and Analysis 78

The idea behind the development of the automated procedures Version 3.2 was to create a temporary daily directory structure on each of the workstations which carry out data processing, and to transfer observation files and results files from and to the archiving workstation monix. This NFS server–client workstation configuration required changes to the automated procedures Version 3.1, mainly related to data transfer issues, i.e. the copying of observation files or results files from a previous processing stage into the temporary directory structure on the current processing workstation. Additional functions were also necessary in order to push the results of the current processing stage back onto the archiving workstation and to allow the removal of the temporary daily directory structure on the processing workstations.

In principle, the automated procedures Version 3.2 are comparable to those of Ver- sion 3.1, in that a processing run is invoked using the top level UNIX Korn shell scripts with extension .now. As in Version 3.1, these scripts define the processing environment using variables for directory path definitions and the processing time span. The top level UNIX shell scripts then invoke the GAS D shell scripts, the second level, which can be identified by their extension *.dates. These GAS D scripts check the processing time span specified for plausibility and carry out the processing loop over each day specified by the time span in the level one shell scripts.

Similar to Version 3.1, the GAS D shell scripts of Version 3.2 then call the GAS R shell scripts, which define the third level of scripts. The GAS R shell scripts then call the GAS F shell functions, which are the bottom level scripts. Figure4.4lists the filenames for all four levels of the pre–, the network– and the post–processing stages of the automated procedures Version 3.2.

Pre–Processing Stage

As in Version 3.1 (§4.4.1) of the automated procedures, the pre–processing stage is in- voked using the top level UNIX shell script preproc.now. This shell script will exe- cute the GAS D shell script preproc.dates, which will call the GAS R shell script preproc.rprocess for each day according to the time span defined by the user. The

Chapter 4. Automated GPS Processing and Analysis 79 shell script UNIX *.now preproc.now GAS D shell script GAS R shell script preproc.rprocess GAS F shell functions preproc.dates fgetdata funhealth frnxwinchk frin2not fmkabasectlline fmkdirs fprepcopy fprepzip fdetslips fclean fcleprep frunabaseline shell script UNIX *.now GAS D shell script GAS R shell script GAS F shell functions netwproc.now netwproc.dates netwproc.rprocess fdefcheck fmkdailydirs fmknetwdirs fgetephems fgetdata2 fnetwctlfilein fnetwindata fnetwsats fnetwproc fnetwstns fnetwatmos fnetwambig fnetwbline fnetwsnx fnetwrun fnetwzip fnetwcopy shell script UNIX *.now GAS D shell script GAS R shell script GAS F shell functions postproc.now postproc.dates postproc.rprocess fpoprdefcheck fpoprmkdailydirs fpoprcopy fpoprgetdata fpoprmkdirs fpoprjdaycar fgetpoprjdayxyz fgetpoprjdayplh fpoprzip

Figure 4.4: Automated Procedures for GPS Processing with GAS (Version 3.2).

GAS R shell script then calls each GAS F shell function of the pre–processing stage as listed by their file names in Figure 4.4.

The GAS F shell functions for the pre–processing stage are essentially the same as in Version 3.1. Modifications were made in the GAS F shell function getdata to account for the NFS server–client workstation configuration between archiving and processing workstations. Furthermore, the GAS F shell function rin2not, which creates the FILTER control file was modified due to problems occurring during cycle slip detection of the first session of the first day of the GPS week. It was noticed by the author that the automated procedures sometimes failed to detect and correct cycle slips in this session. The GAS processing module PANIC would report a large cycle slip within this time period and would crash thereafter. By removing the GPS observations of the first 15 to 20 minutes however, the procedures were able to clean these data. It was therefore decided, to implement the

Chapter 4. Automated GPS Processing and Analysis 80

removal of the first 15 minutes for the first day of the GPS week, as a standard approach within this research.

Slight changes were carried out on the GAS F shell function cprsfiles2 of Version 3.1 (§4.4.1), which removes and compresses observation and processing files after the pre– processing stage. In order to make its file name conform with other shell function names of the procedures Version 3.2, it was also renamed to prepzip.

The introduction of designated workstations for automated processing and archiving of GPS data, required a GAS F shell function that would push the temporary created daily directory structure on the processing workstations geodix, ukcogr and defix onto the archiving workstation monix. This was accomplished, by introducing the new shell func- tion prepcopy, which transfers amongst others, the cleaned NOTT2 format observation files and the session and baseline dependent processing files to the archive procres.

Network–Processing Stage

As in Version 3.1 (§4.4.1) of the automated procedures, the network–processing stage is invoked using the top level UNIX shell script netwproc.now. This script will exe- cute the GAS D shell script netwproc.dates, which will call the GAS R shell script netwproc.rprocess for each day to be processed. The GAS R shell script will then call each GAS F shell function of the network–processing stage as listed by their names in Figure 4.4.

As with the pre–processing for Version 3.2, the modifications necessary to the network– processing of Version 3.1 were mainly related to the separation of the workstations ac- cording to their main tasks. Besides that, path definitions had to be modified in several procedures in order to account for the new processing results archive procres being on workstation monix.

Since December 2001, the IGS produces its ephemeris products in the new realization of the ITRS, the ITRF2000 (Weber,2001). This required an update of the GAS R shell script netwproc.rprocess to accommodate this new reference frame.

Chapter 4. Automated GPS Processing and Analysis 81

After the slightly modified GAS F shell function defcheck has checked the user– definitions, the new GAS F shell function mkdailydirs checks whether a daily directory structure for the current processing day already exists on this processing workstation and if not, creates it. GAS F shell functions getephems and getdata2 were both modified in order to incorporate the transfer of the precise ephemeris, the GAF and the cleaned NOTT2 format observation files to the processing workstation using the NFS server-client workstation configuration. The GAS F shell function getdata2 also copies GPS baseline dependent files, i.e. the bsatfile.out containing the base satellites for each baseline to be used in the PANIC adjustment (Booth,2000).

At this stage, the PANIC control file and the PANIC default control file are created using a number of GAS F shell functions, this is essentially carried out in the same way as described for the automated procedures Version 3.1 (§4.4.1).

Finally, after the GAS processing module PANIC has been executed and a network solution has been obtained, the network solution files are compressed using the GAS F shell function netwzip, which varies slightly from the GAS F shell function zipdata in Version 3.1. The new GAS F shell function netwcopy, then copies the complete network processing directory to the processing archive procres on workstation monix.

Post–Processing Stage

The post–processing stage of the automated procedures Version 3.2 is invoked as in Version 3.1 (§4.4.1) using the top level UNIX shell script postproc.now. This script will execute the GAS D shell script postproc.dates, which will call the GAS R shell script postproc.rprocess for each processing day. The GAS R shell script will then call each GAS F shell function of the post–processing stage as listed by their file names in Figure 4.4.

As with the pre– and network–processing procedures for Version 3.2, the modifications necessary to the automated procedures of Version 3.1 were mainly related to the separation into processing and archiving workstations. Path definitions in several shell scripts and

Chapter 4. Automated GPS Processing and Analysis 82

functions had to be amended in order to accommodate the introduction of the two archives procres and finalcoords on workstation monix.

The large number of CGPS stations in the re–analysis of the data set caused problems with the baseline definition, which is carried out during the execution of GAS D shell script postproc.dates_{. This affected in particular, the network combination mode (§}4.4.1) of the post–processing procedures. Here, the auxiliary C program DEFBLNS (Booth,2000) is used to generate a temporary file containing the number of all GPS baselines to be processed and a list of the associated CGPS station names. DEFBLNS is an independent module, which receives its input parameters as UNIX command line arguments handed over at invocation. This list however, can only contain a limited number of elements and since the baseline vectors of all 25 CGPS stations are to be combined in one network, the argument list was too long for the UNIX shell. In the new approach it was decided to hand over the networks themselves rather than the individual stations. Using the newly developed auxiliary Perl script netwdefblns.pl the problem was solved. netwdefblns.pl reads a list of arguments from the command line which must include the root and project directories, the GPS week, the base station and the list of networks. The command to execute Perl script netwdefblns.pl may look like:

# netwdefblns.pl /usr2/people/tgproc3 tgcogrs 1024 iesg cls1 cls2 cls3

with /usr2/people/tgproc3 and tgcogrs defining the paths to the root and project directories, 1024 being the GPS week, iesg being the 4–character base station name, and cls1, cls2, and cls3 being the networks to be combined. In order to produce a list of GPS baselines from the list of networks handed over, netwdefblns.pl requires the network definition file, which will be introduced later in §4.5.2.

As with the GAS R shell shell script netwproc.rprocess of the automated procedures Version 3.2, the GAS R shell script postproc.rprocess also needed modifications with respect to the change of the reference frame of the IGS precise ephemeris to ITRF2000 in December 2001.

The first GAS F shell function to be called by shell script postproc.rprocess is poprdefcheck. There were few changes in this version of the GAS F shell function

Chapter 4. Automated GPS Processing and Analysis 83

compared to its previous version. A check for the existence of the newly introduced coordinate time series directory finalcoords on workstation monix was added.

An additional GAS F shell function was needed that would check for the existence of the daily directory structure on the processing workstations and create the directory tree if needed. This new shell function poprmkdailydirs would be called before poprmkdirs, which is a modified version of shell function mkpoprdirs of the procedures Version 3.1 (§4.4.1).

The GAS F shell functions getdata needed minor changes in order to provide the PANIC network solution files and the cleaned NOTT2 format observation files using the NFS server–client configuration. This new version of the shell function also un–compresses the copied files so the shell function unzipdata of Version 3.1 was no longer required.

The GAS F shell function poprjdaycar did not require any modifications from previ- ous version, however functions getpoprjdayxyz and getpoprjdayplh, which extract the cartesian and geodetic coordinates from the CARNET solution files, needed updating with respect to the new coordinate time series archive directory finalcoords on workstation monix.

After the CARNET execution, the GAS F shell function poprzip compresses the post–processing directory. This file was based on zipdatantp of the previous version of the automated procedures. The final GAS F shell function to be called during the post–processing stage is the new shell function poprcopy. It pushes the post–processing directory into archive procres onto workstation monix.