Such errors also apply to the vertical which may be more important than the horizontal when discussing multi-level observations (sondes and soundings). The issue of representativeness error can also arise from not being able to represent small temporal scales.

For most observations, the assimilation deals with the representativeness error (which can be estimated) by incorporating it into the overall observation error (i.e. observation error = instrument error + representativeness error) and weighting the impact of the observation in proportion to the inverse of the observation error. However, in some cases the representativeness error is considered so large that it is impracticable to use the observation. Examples are surface temperature observations which, overland, are subject to local (small-scale) heating effects and surface winds over land which are subject to local unresolved orographic effects. Such observations are not used in the larger scale models.

In addition to transforming and formatting the observations, the pre-processing step provides additional information to the quality control and assimilation systems such as 'data use flags', determined from station list information, showing whether or not a variable from a given observation should be used, initial probability of error, observation error values, and background error estimates. The latter using algorithms which relate that error to components of the synoptic situation (e.g. pressure tendency, pressure gradient, wind speed); these algorithms are 'trained' using the monitoring data.

The process of introducing observations during the assimilation process requires that the observations be compared in some manner with the first-guess information from the model. The ideal situation is for the model to be transformed into an observation equivalent. For practical reasons our current system requires some manipulation of the observations such that they are appropriate for assimilation.

Back to top

There are two components to the OPS termed extract and process. The extract component retrieves the raw observations from the central observation database, known as the MetDB, and calculates background values at the observation locations. The process component then performs the quality control, converts the observations if necessary and then reformats them ready for use in the operational forecast.

There are various facilities available to switch off a particular observation type in case a problem develops, such as corrupt data. Also, a record of the number of observations from each type is kept and if the expected number of observations is not received, the forecasters may be alerted as it may have implications on how the model forecast is interpreted.

After the forecast has finished the OPS is run again on the same set of observations. This time however, the analysis values are calculated at observation locations and this information along with the results from the quality control is merged back into the MetDB so that monitoring of the observations can be performed.

The software for the OPS has been written entirely in-house, sharing code with the main forecast model and assimilation system where possible to ease maintenance and ensure compatibility. It has been written in Fortran 90 and is designed to be portable across different platforms. The system is modular with tasks common to several observation types being performed in generic routines and type-specific tasks being run in separate modules. The same system is used for processing observations for several models including the main atmospheric model, the sea-surface temperature analysis system, the wave model and the ocean-atmosphere (FOAM) model. Operationally it is run on the Met Office's supercomputer and for some observation types, notably certain satellite data, it is run in parallel mode due to the number of observations involved. A user-friendly graphical user interface has been written so that the OPS can be run with no knowledge of the internal configuration.

Back to top