Being a common data analysis tool, there are a number of FFT libraries available in various languages. We therefore decided that it may be more efficient to use a third party library for a number of reasons and given that there were many available, we assumed that at least one package could be found that would meet our requirements. Some considerations affecting our choice of FFT packages is the format of the FFT routine, the language they were written in and whether it was a stand alone library, or simple class or a template class. The first library found in our research was the Fastest Fourier Transform in the West (FFTW) library from MIT. This library is widely referenced and documented, and is reputed to be the most efficient FFT library in existence. The FFTW library, however, was written in C, and was therefore discarded an attempt to maintain language consistency through the project. In addition, is the FFTW is quite large, and with the number of dependent libraries for GDMS increasing, it was preferable to find a smaller library. Another candidate was discovered after testing had already commenced with the FFTW library. This was a complex template class to compute a FFT written in C++ (Arndt, 2002), and was considered a suitable choice as it was less complex than FFTW, and also suited our loose Object Oriented design. A further benefit of using this implementation of an FFT was due to the fact that it was a Template Class object was, therefore, not restricted by type. This gave us greater flexibility in the type of data that could be FFT and what format the data would be returned in. For example, we might desire simple double values for PSD plotting, or perhaps complex values for further processing after the FFT had been preformed. The FFT class also provides the ability to perform inverse FFTs on a given set of data. As far as the issue of speed was concerned, no evidence was found during the testing of the complex template FFT class to suggest that it would be much slower than FFTW. We therefore decided to integrate this implementation into the project. The FFT class could not be integrated without modifications. Firstly, there was an issue with the sign of the Fourier transform. This refers to the FFT theory section of this document where the standard Fourier formulae were discussed. The original FFT algorithm operated contrary to this standard and it produced incorrect results. Specifically, the algorithm implemented used the opposite signs for forward and inverse transforms. To overcome this problem, the algorithm needed to be modified such that it return the conjugate of what it originally computed, thereby producing the correct results. This problem was overlooked in the initial algorithm selection process and appeared only later in the unit testing. Further information specific to testing can be found in the Testing chapter later in this document. Another integration problem occurred because of the way in which the original template class deals with data structures. Firstly, the class computes FFTs on and returns an array of data, where as GDMS uses matrices to pass data from class to class and thus it needed to be modified to accept this data type. Another change that was required was that the FFT library needed to modified to calculate a frequency scale in order to enable PSD plots to be graphed. To calculate this scale, the FFT class first determine the sampling rate of the data. This is achieved by examining the distances between consecutive sample dates, the sampling rate simply being the distance between them multiplied by the number of days in a year. This implementation, however, assumes that the data is regular and in fact, functionality in the FFT class has been implemented to prevent the transformation of irregular data. The period used for the sample rate calculation is one day. The frequency is then calculated by taking the inverse of the sample rate and is measured in cycles/day. In the frequency domain analysis, the GDMS package currently only carries out PSD plotting and inverse IFFTs. Additional functionality such as the FFT class returning the raw complex FFT data is a reasonably trivial task to complete. This would allow operations on the complex data resulting from the FFT if required. Its omission from the final specifications was solely due to time constraints. This functionality is already supported within the FFT framework, so adding this in future releases should be trivial. A further enhancement to the frequency domain analysis of the GDMS, would be to allow the removal of erroneous data in the frequency domain, and then allowing the user to transform the data back into the time domain via an Inverse FFT. This would be an extremely useful function, as the detection and removal of erroneous data, such as signal noise is not easily achieved in the time domain but is reasonably trivial in the frequency domain. By allowing the transform of the remaining data back into the time domain, the effects of removing the erroneous signals can be determined.