MichaelStill (964076) DanielFernandez (991672) BlakeSwadling (982087) NickWheatstone (983131) KristyVan Der Vlist (983118) Tue Mar 5 14:15:16 EST 2002 This proposal outlines our intention to develop a package for use in the analysis of GPS Global Positioning System, VLBI Very Long Baseline Interferometry and SLR Satellite Laser Ranging data on tectonic movement. The data is extensive, covering around ten years of measurements from stations around the globe. The GPS, VLBI, and SLR data have various anomalies due to their different vulnerabilies to conditions, such delay due to the ionosphere, temperature, and other considerations including projected stellite orbits. In an attempt to overcome these, we need to perform various transformations on the data, and compare these results. It is intended to do this by taking the two input data sets, in a defined format, and through analysis in both the time and frequency domains, merge the data sets into a new data set, making use of those parts of the GPS, VLBI and SLR data which contain the least noise. Some of the techniques employed during this data processing wil include, Fast Fourier Transforms (FFT), Gaussian filter, Gaybor transforms (specgrams) and Power Spectral Density plots (PSD). The group will be faced with numerous challanges throughout the course of this project, including that of technology resources. The amount of data we will be dealing with, has the potential to push available computer resources near their limits. For this reason, efficiency of the package will be of critical concern. Other challenges are discussed in the section labelled risks below. This project is in part a research project, due to the uncertainties of achieving clear results, even with the package functioning correctly, and therefore contains a good deal of risk. However, much of the prossessing has been done before, providing us with the opportunity of having a reasonably well defined starting point. Failure to determine and correctly implement a satisfactory mathematical process (medium, serious repercussions) Data produced could appear to be correct, however, is in fact wrong (high) Complications associated with potential implementation of mathematical routines in unfamiliar languages such as FORTRAN (medium) The completed product not being flexible enough (medium) Failure to achieve deadlines (low) Staff risks such as the illness or death of a team member at a critical stage (low) University of Canberra might be unable to provide the level of support that the group requires (medium) Other risks not yet identified (undefined) Bearing in mind the risks which have been identified so far, it is proposed that the following implementation strategy be undertaken. It is proposed that the group use current Matlab functionality to perform the required data transformations, thus providing a visual representation of the merged data set via the Matlab plotting functions. In this phase we will develop the basic mathematical functions to perform the required tasks. This will take the form of a small executable which parses data giving output in a format conducive to easy verification (possibly comma delimited text). The next phase of the system development is the implementation of the output routines for the system. It is our intention to make these routines flexible so that new output routines can be added as required. In addition, these output routines will be capable of being executed manually so that the output can be inspected and validated using a separate package if required. During this phase an interactive environment where users can import a data set from a file shall be implemented. Consequently, the desired transforms and operations on the data can then be selected from a range of predefined options. This should provide the user with a visual representation of the results of that operation. The fundamental interface options should be: Open / import dataset Save plot Print output These are extensions which are not absolutely required for the product to be functional, but are highly desirable: Graphical user interface improvements Three dimensional visualization of the output of the mathematical engine Other extensions as identified during development These are extensions which would be nice, but are of a lower priority: Scripting engine for the mathematical subsystem The ability to save a selected transform and apply it to other data sets within the graphical user interface The ability to interact with the sample output within the user interface Other extensions as identified during development The honors extensions for Michael Still, Kristy Van Der Vlist and Nick Wheatstone have not been defined at this stage. The group is well aware of the need to identify these logical extensions, which will be undertaken in the next few weeks. It is important to the success of the project that a well defined testing framework is implemented from the earliest stages of development. Regression testing against previous output should occur regularly, with any changes explained and documented. An established testing infrastructure for the project will also be large advantage to subsequent projects which might wish to utilize the software this project will develop. In this report we have explored the problem which we have selected, identified major sources of risk and considered an implementation approach. During subsequent phases of the project we will design the deliverables, clarify the risks and further examine possible implementation approaches.