Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.mrao.cam.ac.uk/~bn204/oof/software-architecture.html
Дата изменения: Mon Apr 4 13:47:52 2016 Дата индексирования: Sun Apr 10 07:40:07 2016 Кодировка: ISO8859-5 Поисковые слова: юпитер |
The design of the OOF software is driven in part by the desire that a single system serves as both the development environment for new algorithms and investigation of new data sets and as the production environment which is used in routine on-line and off-line data reduction.
The architecture of the OOF data reduction software can be summarised in following points:
This mixed language model is an essential feature of the package that makes development and extending the present system much easier.
The functionality is divided between C++ and Python in the following way:
The C++ layer provides the bulk of the numerical processing routines, including:
- Interfacing to FFT libraries (FFTW), implementing far-field to aperture plane transformations and convolutions
- Implementation of the Zernike polynomials and their caching
- Implementation of specialised 2d interpolations, again with caching
- Implementations of models of aperture-plane illumination
- Routines for simulating OOF data-sets
Also implemented in the C++ layer are interfaces to some required libraries, such as:
- I/O of FITS file binary tables (using
cfitsio
)- Plotting (
pgplot
)
The Python provides user-facing wrapper routines:
The use of Python however also allows following very important facilities:
Efficient and ergonomic inspection of the state of C++ objects at any intermediate stage of computation
“On-line” decision on the algorithms to be run through use of virtual functions.
For example, the model for the aperture-plane consists of a model of the illumination and of the phase. Each of these is specified as a pointer to an object which is a sub-class of the right base-class (one for each of these two models). The subsequent minimisation calls virtual functions provided by these objects.
The rationale for adopting multiple module architecture is simply that the OOF holography application was able to re-use some code originally developed for other applications, while it was also clear that some of the code developed for OOF will be (and now is) useful for other, unrelated applications.
Therefore the functionality is split (as well as I could do it) along domain lines as follows:
pgplot
)The following libraries are used:
The de-facto standard Autotools build system is used and has been found to work well on all Linux installations.
At the time of writing, the modules that make up the OOF data
reduction software contain 12000 lines of code (this excludes
auto-generated files, comments and whitespace lines). Of that
approximately 9000 are in C++, 2500 are in Python, and the remainder
are Makefile and configure.ac
scripts.
Obviously, it should be pointed out that some of this code relates to features quite unconnected with OOF data reduction and some of it relates to features that were developed in connection with OOF but are not in production use.