Operational European Flood Forecasting - Environmental Modelling: Finding Simplicity in Complexity - page 408

Table 25.2 (continued)

Data type Data set/activity Specification

Computing system
requirements

High-performing computing Probabilistic flood forecasting contains many computer intensive tasks.

This includes reception of data, pre-processing of data including
downscaling and correction, running the hydrological model several
times with multiple weather predictions, production output maps,
transfer of output maps to end users, publishing on the web. May
require use of supercomputer and/or parallel processing techniques.

Large storage capacity All the results and many of the intermediate modelling results need to be

achieved for future analysis or additional research to improve the
forecasting system.

Large band width It maybe necessary to transfer the results and other data to en-users. A

large data volume is quickly accumulated if one uses several
meteorological forecasts.

365/24 service An operational service needs to be guaranteed to produce results 24

hours a day, 365 days a year.

High-performing web
platform

publishing of results and decision making tool

Alert provision Network of recipients End users of the forecast must be well informed about EFAS processes

and procedures, trained in receiving flood alerts and involved in
discussion of future developments.

Decision rules Rules should be clearly defined (and followed) regarding when and how

flood alerts should be given. They should also be reviewed on a regular
basis.

Science research
support

Model assessment and
improvement

As well as a robust operational technical flood forecasting team, science
research support is essential to an operational system. This should
include post-event performance analysis of the system, improved
model calibration, model improvements and development of
appropriate model assessment routines. For example new assimilation
of satellite data or the testing of the communication of probability.

meteorology such as precipitation (amount and inten-
sities), antecedent soil-moisture content, soil type and
land-use type. During the design of LISFLOOD, process
descriptions were selected in order to make the best use
of the available prior spatial databases and so reducing
the number of 'free' calibration parameters. In addition,
process descriptions that are overly complex, very com-
putationally demanding or irrelevant at the scale of large
catchments have been avoided. As changes and exten-
sions to the model are required on a regular basis one
of the main drivers for its development was the need
to have a model code that can be easily maintained and
modified. The model has been extensively tested and
calibrated for various large catchments across the globe
(Xingguo et al ., 2006; Feyen et al ., 2007; He et al ., 2009;
Thiemig et al ., 2010, Mo et al ., 2005) as well as for smaller

scale, flash-flood-prone catchments (Younis et al ., 2008a;
Alfieri et al ., 2011).
Van der Knijff et al . (2010) provide a comprehen-
sive description of the model to which we direct the
interested reader and from which we provide a very
condensed summary here. Figure 25.4 gives a schematic
overview of LISFLOOD's internal model structure. As the
figure shows, the model is made up of a two-layer soil
water balance submodel, submodels for the simulation
of groundwater and subsurface flow (using two paral-
lel interconnected linear reservoirs), a submodel for the
routing of surface runoff to the nearest river channel, and
a submodel for the routing of channel flow (not shown in
the figure). The processes that are simulated by the model
include snow melt (not shown in the figure), infiltration,
interception of rainfall, leaf drainage, evaporation and