Models and Modeling in FEWS Part I

1. Models and Modeling in FEWSPart I Micha Werner Deltares & UNESCO-IHE

2. Objectives • Discuss the approach to integration of models in FEWS (CHPS) • General approach • Limitations and considerations • Discuss integrating models in FEWS • Rainfall-Runoff, Snow, Groundwater • Hydrodynamic routing • Model and model adapter availability • Aspects of integrating models with FEWS • PC Raster • Mixing models & model concepts • Error correction

3. Program: Models in FEWS I • Part I • Concepts of integrating models in FEWS (repeat) • Distributed Hydrological Modeling • Forcing, integration, model set-up, calibration, snow, groundwater • Case studies: WASIM-ETH; PCRGLOB • Integration of models using PCRaster • Concepts of PC Raster • Spatial data (pre/post) processing • Linking PC Raster models (adapter, PCRaster-Python)

4. Program: Models in FEWS II • Part II • Hydrodynamic routing models • Model types, forcing, integration, tidal boundaries, internal boundaries, Inundation modeling, 1D & 2D modeling, regulation • Case studies: Firth of Clyde, Scotland; Rhine • Aspects relevant to model integration • Approaches to bias correction

5. Integration models in FEWS(repeat) In this section we will discuss some background to the running of models from FEWS. The objective is to establish an understanding of the concept of how this interaction works, without going in to the detail of how such interaction is considered. We will look at how data is exchanged, what data is exchanged and the different formats that data is exchanged in. This section will not outline how to configure FEWS to run models. This can be obtained in other classes.

6. Integration of models in FEWS • It is important to understand the principle on which FEWS has been built; • Delft FEWS provides an interface to running models in a forecast environment • There are in principle no inherent modeling capabilities • All models linked FEWS follow the same approach • Data is exported to the model in a defined format (Published Interface) • Model runs using its own native formats • Data is imported from the model in the same defined format (PI)

7. Delft-FEWS (concept) simulated (forcing) data • Delft-FEWS • import • validation • transformation / interpolation • data hierarchy • general adapter • export / report • administration (data, forecasts) • viewing (data, forecasts) • archiving • … PI models import external export & dissemination

8. export import xml files (PI) xml files (PI) run run pre-adapter post-adapter run native files (e.g. txt) native files (e.g. txt) model Running models – how does it work 1: Export model inputs 2: Run pre-adapter 3: Run model 4: Run post-adapter 5 Import model results General Adapter Module local datastore FEWS model

9. Models linked to FEWS • All models follow the same principle – irrespective of model developer and/or concept • “Complete” list of models integrated with Delft FEWS • http://public.deltares.nl/display/FEWSDOC/Models+linked+to+Delft-Fews • Generally the “owner”of the model develops an adapter for that model to the FEWS interface

10. Communicating data to models 0D – point time series data • FEWS database holds dynamic data (primarily) as well as static data • Dynamic data relevant to exchange with models • Time series data (0D, 1D, 2D) • States 2D – longitudinal time series data 1D – longitudinal time series data

11. Communicating data to models • Most models applied in a hydrological forecast environment are initial state type models – i.e. require a known state to start from. Forecast period - Model requires inputs (forcing) across this period Start of forecast period Model typically also “returns” state during forecast mode – but this will generally not be used 00:00 12:00 12:00 00:00 Update run provides a state to start from (could also be default state by choice) Model returns data for same run period

12. Communicating data to models • To FEWS inputs and outputs to the models can be in any of the three types • Generally in the form of 0D time series data • For distributed models, 2D data is common • For hydrodynamic models, 1D data is sometimes used • Mixing formats when running any particular model is not an issue • States handled in “native” model format – tagged with a date/time • Other data exported from FEWS database to model • Model parameter sets (XML file that FEWS can read) • Model parameter/dataset (binary file that FEWS just passes on) • Run file with details on model run (start, end time, file paths/names)

13. Communicating data to models • Limitations & Considerations • There is no model specific “knowledge” passed between FEWS & Model and vice versa • Advantage: guarantees an open system – model independent • Advantage: FEWS has no necessary knowledge of what model is being run • Disadvantage: Model is not “aware” of all data in database unless made aware – not all information can be passed. • Several layers of exchange – often file based • Advantage: independent, easy to test, clear interfaces • Disadvantage: many intermediate steps (though focus on options to make this more efficient)

14. Questions…

15. Running distributed models In this section we will discuss the use of distributed models in FEWS. Similarities and differences with lumped models are briefly discussed. Considerations on integrating models with FEWS are discussed, as well as how models are combined with routing models. Examples of some distributed models integrated are discussed

16. Distributed models versus lumped models • Lumped models consider a watershed or basin as a single lumped entity • Model inputs at the basin level: e.g. MAT & MAP • Model parameters defined at the basin level • Applied as a semi-distributed concept • Basin divided into several sub-basins (horizontally / vertically)

17. Distributed models versus lumped models • Distributed models discretize a basins in small units • Typically in the form of grids – or other geometric unit • Model inputs required in same discretized form • Model parameters typically defined similarly(in some cases associated to geo-morphological attributes – linked using distributed model layer of these attributes)

18. Semi-distributed model Fully Distributed model Lumped model From lumped to distributed

19. Physically based versus conceptual models • Conceptual model: Conceptual representation of catchment processes: Fluxes and Stores • Conservation of mass • Physically based model: Explicitly model processes in catchment as described by the laws of physics • Conservation of energy, momentum, mass DHM is a distributed version of the SAC conceptual model

20. Physically based models 43 REWs (Strahler 2nd order) Representative Elementary Watershed (REW) Model Hydrological Response unit approach Grid based distributed approach (e.g. Mike-SHE)

21. Physically based vs Conceptual models • Physically based models • Pros; • Physical processes modeled in the best possible manner • Changes in catchment conditions can be incorporated in a plausible way • Cons; • Models are data intensive – require detailed information of catchment properties (topography, soil, vegetation etc.) • Scale issue – balance between detail of process response and lumping response into “units” of e.g. 1x1 km • Reductionist approach – assumes that all processes fully understood and adequately described.

22. Hydrological (Rainfall/Snow) Models linked to FEWS (Examples)

23. Question/Poll • Physically based models will always provide better forecast results than conceptual models • True • False

24. Running a distributed model in a workflow Example workflow Import workflow Fill gaps in precip & temp Interpolate to model grid Principle is exactly the same as when running a lumped model However, data processing steps may differ Merge Grids Run Distributed model Export workflow Run Routing Model

25. Inputs & Outputs for a distributed model • Required inputs will depend very much on the type of model being used • Typical set of inputs (gridded at the same resolution as the model) • Rainfall • Temperature • Evaporation/Humidity/Vapor Pressure/Temp (wet bulb) • Incoming Radiation • Set of outputs will equally depend on type of model being used • Point (accumulated) & Gridded outputs • Flow, runoff, soil moisture (layers), evaporation, SWE, etc.

26. Inputs & Outputs for a distributed model • Pre-processing of model inputs likely to be different in forecast and in update period • This may introduce bias in (distributed) inputs – prep-processing? • Some distributed models provide capabilities to interpolate (observed) meteorological data. Preferably this should be done outside the model or in two steps to allow merging (update-forecast period; backup time series) Observed meteo. variables Meteorological forecast grids Interpolation Downscaling Interpolated (observed) meteorological grids Downscaled meteorological grids Distributed Model (simulation) State Distributed Model (simulation) Forecast period Update period

27. Case Study • Distributed modeling in Switzerland • Motivation • Currently lumped model used for all catchments: HBV Conceptual model • Experience showed that model does not quite capture dynamic response of (higher elevation) catchments • Modeling distributed processes such as Snow • Two models piloted in smaller sub-basins • PREVAH – Sihl & Linth Basins • WASIM – Emme basin • Outputs of Dist. Model routed into HBV model chain Elevation model for the Emme basin As used in WASIM (500m resolution)

28. Case studies • Integration of WASIM-ETH • Model developed at ETH-Zurich • Fully distributed grid based model • Models main hydrological processes • Interception • Infiltration • Unsaturated zone (Richard’s/Topmodel) • Glacier & Snowmelt Processes modelled (in German!)

29. Case Studies • Integration of WASIM-ETH • Adapter developed 2010 to run WASIM from FEWS. Pilot implemented for Emme catchment

30. Observed meteorological variables Meteorological forecast grids WASIM (interpolation) Downscaling Interpolated (observed) meteorological grids Downscaled meteorological grids WASIM (simulation) State WASIM (simulation) Output grids & discharge (selected locations) Output grids & discharge (selected locations) Case Studies • Integration of WASIM-ETH

31. Case Studies • Integration of WASIM-ETH • Workflow • Relatively simple structure of workflow

32. Case Studies • WASIM-ETH –Outputs returned to FEWS (currently)

33. Case Studies Snow water equivalent

34. Case Studies Direct runoff

35. Case Studies Interflow (unsaturated zone)

36. Case Studies Base flow

37. Considerations on integrating distributed models • Runtime for distributed models can be considerably larger • Example: Emme catchment: 936 km 2 WASIM: Model grid resolution 500m (106x96 cells) UpdateStates run: length: 9 days Run time (preprocessing): 46 sec Run time (model run): 1 min 38 sec HBV: 3 sub-basins Run time (model run): 3 sec • Database sizes can be considerable larger WASIM: Input data processing: 3.5MB Model results: 6.5 MB (of which 10.1 KB scalar time series) HBV: Model results: 7.1 KB

38. Comparison • General impression: WASIM gives a better representation of the dynamic response of the catchment – but often oversimulates

39. Comparison of results from HBV and from WASIM at Eggewil and at Wiler

40. Emme catchment • ARMA error correction at Emmemat & Wiler • Input correction ofr Emmemat & Egge sub-basins

41. Semi-distributed model fully-distributed model HBV Emme-Egge HBV Emme-Emme ARMA Forecast @ Wiler Forecast @ Emmematt Routing HBV Emme-Wiler Forecast @ Emmematt ARMA Issue: distributed model does not make use of observed data in internal gauges Forecast @ Wiler

42. Mixing models to utilize both advantages Semi-distributed model Simulation @ Emmematt ARMA Forecast @ Emmematt Routing Incremental flow @ Wiler ARMA Distributed model requires option to output incremental flow Forecast @ Wiler

43. Distributed models & interaction • Interaction between forecaster & distributed model less obvious than with lumbed model • Example: for Sacramento it is common to change contents of different stores - this is not a realistic proposition with a distributed model • Difficult is that error in simulated flow cannot be easily be attributed to a part of the model • Options • Influencing forcings (distributed) • Selected parameters (e.g. meltrate) • Changing areas of model with similar characteristics • All these will introducing some form of lumping! • Opportunities • Using other data to update model – e.g. snow cover, soil moisture • Active research area

44. Other distributed models: TOPKAPI • TOPKAPI: TOPographic Kinematic APproximationandIntegration • Developed by University of Bologna (Italy) • Applied in operational forecasting system for the Po in Italy, as well as in Spain • Can be applied both in lumped form and in distributed form • Physically based model

45. TOPKAPI linked to FEWS using standard adapter approach • In application in FEWS-Po (Italy) inputs are only rainfall and temperature. • TOPKAPI started life as a research model • Version used in FEWS with FEWS Adapter developed by ProGea http://www.progea.net/prodotti.php?p=TOPKAPI&c=Software&lin=inglese

46. Other distributed models: MODFLOW • MODFLOW: • Three dimensional Groundwater modelling system • Linked to FEWS using adapter approach: developed for use in National Groundwater Modelling System (NGMS, UK) http://en.wikipedia.org/wiki/MODFLOW

47. National Groundwater Modelling System Rolf Farrell (EA-UK): How to make groundwater models useful and accessible for regulatory staff Thanks to Peter Gijsbers for the slide

48. NHI (National Hydrological Instrument)The Netherlands • Build a high resolution integrated hydrological model: • → NHI (National Hydrological Instrument) • Incorporate this in a real time operational forecasting system: • → FEWS-Water management • Support the National Co-ordination Committee for Water Allocation in its decision process under drought conditions • → Information on current status of the system, deficits, deviations from climatology, damage • → Input for official drought publications: “Droogtebericht” Thanks to Peter Gijsbers for the slide

49. NHI (National Hydrological Instrument)The Netherlands • → NHI (National Hydrological Instrument) Distribution Model (national surface water Δt=10d) Meta-SWAP (sub-surface Δt=1d) Mozart (regional surf.wat. Δt=10d) demand/allocate Demand/allocate demand/ allocate Modflow (national ground water model, Δt=1d, 250x250m) Thanks to Peter Gijsbers for the slide

50. NHI (National Hydrological Instrument)The Netherlands • Real time data feeds: • → observations • meteo, sw, gw • → forecasts • weather, river inflow Thanks to Peter Gijsbers for the slide