**6. Software architecture: From models to systems**

576 Risk Management – Current Issues and Challenges

**5.8. The multi-model approach** 

their level of skill.

**5.9. Downscaling** 

that calibration models have a small number of parameters.

information for dynamical model based outlooks are not yet common.

driver of variability, but the GCM does not resolve local topography.

verification dataset will necessarily have large sampling error. For this reason it is desirable

The problem is even thornier, because some circulation regimes such as strong El Nino events are thought to be more predictable than others, so there is every chance other variables may be strongly related to the predicted accuracy of a given forecast. Indeed the practice of ensemble forecasting is designed to reflect such changes in potential predictability. For example the influence of strong El Niño and La Niña events leads to greater predictability of climate anomalies in affected regions during such events. Given this knowledge, information about the state of ENSO should in theory be used to estimate the certainty of seasonal outlooks. Empirical outlooks do just this, but schemes using this

Another approach to the quantification of model error is to combine forecasts from a number of different yet plausible dynamical models. Multi-model combination aims to benefit from a better representation of uncertainty in model physics, model configuration and initialisation strategy. The multi-model approach is widely used in operational weather prediction (out to 7 to 10 days ahead). Model combination is complicated by varying grid resolutions, ensemble sizes, different model skill and mean biases between models, as well as unresolved questions about model weighting. The multi-model approach has been criticized on the grounds that combining a forecast from a bad model with a forecast from a good model may result in a less skillful forecast if one does not weight models to reflect

Another family of model adjustments is motivated by the mismatch between the resolved scale of GCMs and the scale at which most decisions are made. GCMs can provide useful forecasts of atmospheric fields at seasonal timescales but are typically run at coarse spatial resolution such that the direct model output represents spatial averages over thousands of square kilometres (typically grid cells some 100 km in size). This coarse resolution poses a problem for applications that require forecasts at a finer spatial scale, especially in regions where the real topography causes local rainfall to diverge significantly from model grid averages. Where the errors to be corrected are primarily a result of the spatial scale of the GCM, the correction is called 'downscaling'. Downscaling is desired for those Pacific islands where the interaction between the prevailing winds and local topography is a significant

The primary goal of downscaling is to replace the large-scale grid box climate variable, in this case rainfall, with rainfall that is better representative of the local situation. One method of downscaling is that of meteorological analogues. In this approach, large-scale synoptic meteorological fields are used as predictors for small scale variables. The output of a The design of systems for the generation and distribution of GCM based outlooks is architecturally complex. It is here that the interdisciplinary nature of the seasonal forecasting activity becomes clear. In addition to more traditional earth system science involved in understanding coupled ocean-atmosphere processes, the tasks of data processing, data modelling and information system architecture require advanced computing skills. We now outline a general pattern for the design of systems for the delivery of seasonal forecasts to end users which is a generalisation of the implementation described above and in [34].

Four distinct layers can be defined as components of the overall process of turning the outputs of GCMs into seasonal outlooks suitable for use by decision-makers.

The **model layer** comprises the GCM simulating the evolution of the coupled oceanatmosphere system. This component is a complex software system in itself, integrating the ingestion of data analyses (themselves based on multiple networks of observations), the assimilation of these observations into the model integration cycle, and the output of variables of interest. This layer is the domain of earth system scientists and experts in numerical computation. GCMs are typically the result of the combined efforts of a large number of such scientists and engineers working over a long period of time.

In the **forecast generation layer**, forecast products are generated from dynamical model output. This process involves statistical corrections for model biases and may involve the integration of outputs from a number of different models. Decisions about which model outputs to use will be based on the analysis of model performance over an historical period. The resulting derived forecast products are typically stored in self-describing files with additional metadata to support the clients that deliver the outlooks. By storing the generated forecasts in an accessible, metadata rich format they are easily ingestible by downstream clients, whether these are simple viewers or more complex models that use the calibrated model data as one input among many. GCM model outputs may be used to drive other models (for example hydrological models). In general metadata is preserved as data is processed and new metadata added to describe transformations. This enables downstream users of the data to understand its provenance. Metadata curation, while tedious, should be considered a best practice if data is to be made public and its use promoted. Practitioners in this domain will typically be data scientists, statisticians, and climate scientists who work closely with forecast users.

Managing Climate Risk with Seasonal Forecasts 579

post-processed model-based forecasts in standard formats, and exposing web services that

Agile software development methodologies allow technical development to proceed simultaneously with the gathering of user feedback and refinement of designs. They are characterised by short development cycles with clearly defined goals and sub goals. Beginning development early ensures technical issues are solved, avoiding delays if system requirements cannot be completely specified in advance, or scientific results that underpin the forecast products cannot be anticipated. More traditional software development lifecycles, such as the so-called 'waterfall' model, depend on system requirements and

In the agile model of software development, regular user testing takes place at each development increment with user feedback incorporated into the next iteration. A test system may be made available for the use of developers and other project team members. An agile approach suits small and specialised project teams, as the flexibility of the agile approach may hold management risks for a larger development group. This approach

features being specified early and held static throughout the development period.

enables responsiveness to the requirements of the end users of the system.

**Figure 9.** An example of a web-based tool providing seasonal climate forecasts.

The development of web based tools integrating model-based outlooks with climatological information and other contextual information is one means of communicating information

**6.2. A case study: The pacific seasonal forecast portal** 

about climate risk to end users. [36]

provide access to data and meta-data via clearly defined protocols.

**6.1. Designing seasonal outlook products and tools** 

At the **data service layer** forecast data is exposed via a data server, which makes the forecast data available using standard interfaces such as OPEnDAP[35]. At this stage, the generated outlooks are data products, not graphical products. The format of the output is not dependent on the particular dynamical model, or even that the model is dynamical: the forecast is simply a time series of gridded data with descriptive metadata. This layer is the domain of information architects and software engineers with expertise in moving data across networks efficiently.

The **product service layer** provides the means for the majority of forecast users to access the products they require, typically in the form of maps and graphs presented as images, data tables and expert commentary. Such products are developed by climate scientists and associated professionals with expertise in data visualisation, usually in close consultation with forecast users. This layer may take the form of pre-generated images and tables, or of complex applications that obtain and process data directly from the data service layer using web services.

The use of open standards, interoperable systems and simple, clean interfaces simplify the challenge of integrating data from multiple streams into usable seasonal forecasts. Systems need to be interoperable to reduce the cost of exporting and ingesting data, a procedure which is required at all stages of the process from the modelling (where analyses must be ingested for the initialisation of models) to the product services (where potentially large volumes of image and web page requests must be serviced). The use of open standards supports this interoperability. Open standards arise in communities of practice over periods of time, and generally become enshrined in documentation and formally supported by interinstitutional bodies. They are to be preferred over the creation of new *ad hoc* formats and interfaces. Clean interfaces means that coupling between system modules should be kept to a minimum, and that system modules communicate with each other as far as possible using the standards described above. The integration of model outputs into arbitrary decisionsupport systems and downstream models is supported by providing the model output, and post-processed model-based forecasts in standard formats, and exposing web services that provide access to data and meta-data via clearly defined protocols.
