| Home > Research > Ifsdocs > OBSERVATIONS > |
IFS documentation Front Page
Chapter 2. Observations: Types, variables and error statistics
Chapter 3. CMA creation (MAKEMA)
Chapter 4. The FEEBACK task
Chapter 5. The TOOLS task
Chapter 6. Central-memory array (CMA) structure/format
Chapter 7. BUFR feedback data structure/format
Chapter 8. SIMULATED-observations data structure/format
Chapter 9. NAMELISTS
Chapter 10. Processing of scatterometer data
REFERENCES
Previous Section
1.1 Basic principles
The ECMWF data assimilation observation processing system is split into two parts:
| 1) the non-IFS observation processing module (OBSPROC), and |
| 2) the IFS processing module (IFS). |
The main separation line what is done in one or the other module is based on whether a field (e.g. first guess) information is required or not. Thus, the observation processing functions for which field information is not required are dealt with by the OBSPROC, whereas the IFS deals with the observation processing functions for which field information are required. The OBSPROC is also known as the pre-analysis observation handling system.
The main purpose of the OBSPROC is threefold:
| 1) to pre-process the input data for further use by the analysis (IFS), |
| 2) to post-process data used by the analysis, and |
| 3) to provide some observation processing related diagnostics/debugging tools. |
The observation processing/handling in the ECMWF data assimilation system has become very complex. This is mainly due to an increased volume and variety of observations together with more advanced analysis techniques and computers.
The idea is to have:
| (a) efficient, |
| (b) transparent, |
| (c) low maintenance, and |
| (d) comprehensive |
observation processing system so that all the variational analysis observational requirements, in both the operational and the research contexts, can be met. On the efficiency side the use of massively parallel processing (MPP) computers led to a fully parallelized observation processing system. The transparency requirement meant that both the code and the data structuring had to be computer independent. When considering the observation processing system maintenance, the view taken was that it had to be organised in such a way, first, that it should be controlled as much as it is possible externally (no code changes) via namelists and, second, that the code should be modular enough so that when there is a need to change or expand it (for new observations) it can be done with a relative ease. By the comprehensiveness of the system it is meant that only a few job steps (modules) ought to perform all observation processing tasks as well as to accommodate for the future requirements.
Generally speaking, OBSPROC is a namelist driven module with appropriate defaults preset. There are 15 namelists altogether for now (see Chapter 9 `NAMELISTS' ).
The OBSPROC module can be used in two modes:
| (a) single task (workstation version), and |
| (b) parallel (MPP version). |
Parallelization of the OBSPROC was necessary because:
| • the expansion of a large non-homogenous data sets may be time-consuming, |
| • some other computational work is also done at the same time, |
| • on a parallel machine each individual processor tends to be `slow' (especially in scalar mode), |
| • memory requirements for observations processing may be very large, |
| • an MPP may lend itself naturally to distributed data, and |
| • past and present experience shows that the single task job steps are a source of bottle necks. |
Although the parallelization aspects of the observation processing are dealt with by a separate module called OBSORT, the OBSPROC is achieving parallelization by a number of the OBSORT subroutine calls. Effectively, the OBSPROC code is the same for both the parallelized and the single task modes. The parallel version is activated by a namelist parameter.
Either of these two OBSPROC modes consists of a number of observation processing tasks, while in turn each task consists of a number of observation processing functions (see Section 1.3).
Next Section
Previous Section
 |
16.04.2002 |
 |
© ECMWF |
