1. Models and Modeling in FEWS Part I
13 april 2017
Models and Modeling in FEWS Part 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) Delft-FEWS simulated (forcing) data import
13 april 2017
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. 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
xml files
(PI)
export
import
pre-adapter
run
model
run
post-adapter
run
xml files
(PI)
FEWS
model
native files
(e.g. txt)
native files
(e.g. txt)

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
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
00:00
12: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. From lumped to distributed
Lumped model
Semi-distributed model
Fully Distributed model

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)
Lumped (or semi-distributed)
SAC-SMA
SNOW-17
HEC-HMS
PDM
PACK
HBV
MIKE-NAM
URBS
NWS
USACE
CEH-Wallingford
SMHI
DHI
Don Carrol US
Po, Nile, etc
England & Wales, Scotland
Rhine (CH & DE)
England & Wales, Spain, Po
Mekong
Distributed
Grid2Grid
WASIM-ETH
PREVAH
TOPKAPI
Vflo
REW*
WFLOW*
MODFLOW
ETH Zürich/Jürg Schulla
WSL
ProGea/Uni-Bologna
Baxter Vieux
Deltares
Deltares & Adam Taylor
Switzerland
Italy, Spain
Taiwan
Research Applications
England & Wales (NGMS)

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)
Update period
Forecast period

27. Case Study Elevation model for the Emme basin
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
13 april 2017
Case Studies
Integration of WASIM-ETH
Adapter developed 2010 to run WASIM from FEWS. Pilot implemented for Emme catchment
Model Inputs (all gridded)
Temperature
Precipitation
Vapour Pressure
Wind Speed
Global Radiation
Sunshine Duration

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

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

32. Case Studies WASIM-ETH –Outputs returned to FEWS (currently) Variable
Parameter identifier
Unit
Description
Precipitation (snow)
grid and scalar
P.uh.snow mm
Precipitation on each grid cell in solid form
Precipitation (rain)
P.uh.rain
Precipitation on each grid cell in fluid form
Runoff (direct)
q.uh.dir
Direct runoff from each cell
Runoff (Interflow)
q.uh.ifl
Runoff as interflow from each cell
Runoff (baseflow)
q.uh.bas
Runoff as baseflow from each cell
Snow water Equivalent
SWE.uh
Snow water equivalent in each grid cell
Evapotranspiration
E.uh.etr
Evaportranspiration from each grid cell
Root Zone Moisture content
RZM.uh
Soil moisture content in the root zone for each grid cell
Runoff (total)
scalar only
Total runoff
Discharge (total)
Q.uh
m3/s
Total discharge at each point (includes all runoff from upstream of that grid cell point)

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

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

47. National Groundwater Modelling System
13 april 2017
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
13 april 2017
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
13 april 2017
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
13 april 2017
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

51. NHI (National Hydrological Instrument) The Netherlands
13 april 2017
NHI (National Hydrological Instrument) The Netherlands
FEWS-Water management output: ground water levels vs. climatology
Thanks to Peter Gijsbers for the slide

52. NHI (National Hydrological Instrument) The Netherlands
13 april 2017
NHI (National Hydrological Instrument) The Netherlands
FEWS-Water management output: drought damage (fraction)
Thanks to Peter Gijsbers for the slide

53. NHI (National Hydrological Instrument) The Netherlands
13 april 2017
NHI (National Hydrological Instrument) The Netherlands
FEWS-Water management output: surface water deficit
Thanks to Peter Gijsbers for the slide

54. NHI (National Hydrological Instrument) The Netherlands
13 april 2017
NHI (National Hydrological Instrument) The Netherlands
National drought publication
Thanks to Peter Gijsbers for the slide

55. MODFLOW & FEWS Current versions of MODFLOW supported: Modflow 96 & 88
Inputs
NGMS: Recharge, Abstractions (wells)
NHI: Recharge calculated in coupled Modflow – MetaSWAP model (unsaturated zone)
Outputs (gridded, or sampled at a point)
heads, flows, streamflow accumulations
Size and runtime is an issue!
Model set-up typically hosted outside of FEWS database
Runs may take days to complete – not for real time forecasting!

56. Questions…

57. PCRaster and distributed models
In this section we will discuss the PCRaster package, how this has been integrated within Delft FEWS. A brief background to the package is given, and the two methods with which it has been used in FEWS are explained. Case studies are used to illustrate each of the two methods of use.

58. PCRaster and DelftFEWS
13 april 2017
PCRaster and DelftFEWS
Key concepts:
Script language for gridded data
Many hydrological functions (e.g. kinematic wave, catchment delineation etc)
Extensively used within the hydrological research community
Integrated into Delft-Fews using in-memory XML link (pcrTransformation module)
Can be used by everybody with a DelftFEWS license
Also available as external (command line) model that can run in DelftFEWS via a General Adapter
Requires license from PCRaster supplier
Free for personal use (download)

59. PCRaster From the pcraster web-site (http://pcraster.geo.uu.nl/)
13 april 2017
PCRaster
From the pcraster web-site (
“The PCRaster Environmental Modeling language is a computer language for construction of iterative spatio-temporal environmental models. It runs in the PCRaster interactive raster GIS environment that supports immediate pre- or post-modeling visualization of spatio-temporal data.”
“The PCRaster Environmental Modeling language is a high level computer language: it uses spatial-temporal operators with intrinsic functionality especially meant for construction of spatial-temporal models. “
Go to web page ….
Download page:

60. PCRaster
PCRaster provides a simple environment with which dymanic spatial models can be build => Dynamic GIS environment
Short demo (from PCRaster documentation)

61. PCRaster Demo
Calculate runoff over an area using a simple water balance model
(explained fully on

62. PCRaster Demo
Precipitation at 3 rainstations, mm/6 hours

63. PCRaster Demo Create Thyssen net from available rainfall stations
initial
# coverage of meteorological stations for the whole area
report RainZones=spreadzone(RainStations,0,1);

64. PCRaster Demo Variable infiltration map given soil properties 1 2.1
1 2.1
2 8.3
3 19.0
initial
# create an infiltration capacity map (mm/6 hours), based on the soil map InfiltrationCapacity=lookupscalar(SoilInfiltrationTable,SoilType);

65. PC Raster Demo
Create runoff direction map: local drainage direction (ldd)
(Detail)
initial
# generate the local drain direction map on basis of the elevation map
Ldd=lddcreate(Dem,1e31,1e31,1e31,1e31);

66. PC Raster Demo Ready to run!!! See
dynamic
# calculate and report maps with rainfall at each timestep (mm/6 hours)
SurfaceWater=timeinputscalar(RainTimeSeries,RainZones);
# compute both runoff and actual infiltration
RunoffPerTimestep,Infiltration=
accuthresholdflux, accuthresholdstate(Ldd,SurfaceWater,InfiltrationCapacity);
# output runoff, converted to m3/s, at each timestep
report RunOff=RunoffPerTimestep/ConvConst;
See
Run the model for 28 timesteps  21.bat
Time loop of rainfall input per zone  9.bat
Time loop of runoff  22.bat

67. PC Raster Demo Sample runoff at points of interest dynamic
# output runoff (converted to m3/s) at each timestep for selected locations
report RunoffTimeSeries=timeoutput(SamplePlaces,RunOff);

68. Examples of useful PCRaster commands..
13 april 2017
Examples of useful PCRaster commands..
COVER
Result = cover( expression 1, expression 2,... expression n)
Can be used as data hierarchy but unlike FEWS it does this on a per pixel base.
Example: Result1.map = cover(Expr1.map,sqrt(9))
Result1.map = cover(Expr1.map,sqrt(9))

69. Examples of useful PCRaster commands..
13 april 2017
Examples of useful PCRaster commands..
WINDOWTOTAL/AVERAGE/MAX/MIN
Result = windowaverage( expression, windowlength )
Moving window calculations. Smoothing etc…
Example: Result1.map = windowaverage( Expr.map, 6) ))

70. Examples of useful PCRaster commands..
13 april 2017
Examples of useful PCRaster commands..
if then else
Result = if( condition then expression1 else expression2 )
If then else is eveluated on a per pixel base. Not for model control but to assign values based on conditions per pixel.
Example: Result.map = if(Cond.map,Expr1.map,Expr2.map)

71. Examples of useful PCRaster commands..
13 april 2017
Examples of useful PCRaster commands..
Key concept in environmental modelling, the LDD (Local Drainage Network)
Used for:
Catchment deliniating
Downstream routing of material
Calculating upstream area
etc…

72. PCRaster and DelftFEWS
13 april 2017
PCRaster and DelftFEWS
Can be used for simple operations or to build (very) complex distributed hydrological models
Many useful functions, see pcraster web-site

73. Hydrological modelling
13 april 2017
Hydrological modelling
A simple distributed hydrological model (demo from PCRaster) – 1/2
# model for simulation of rainfall and evapotranspiration
# one timeslice represents one month
binding
RainTimeSeries=rain12.tss; # timeseries with rainfall (mm) per month
# for two rain areas
Precip=rain; # reported maps with precipitation,
# rain is suffix of filenames
RainAreas=rainarea.map; # map with two rain areas
VolumePrecip=volrain.tss; # reported timeseries with volume rain per
# month (cubic metres per second)
CropCoeffTable=crcoefa.tbl; # column table with crop coefficients for
# classes on LandUse
LandUse=landuse.map; # map with nominal landuse classes 1,2,3
EvapRefTimeSeries=evaref12.tss; # timeseries with reference
# evapotranspiration (mm) per month
PrecipSurplus=rainsur; # maps with precipitation surplus (mm/month)
InitSoilwater=initsw.map; # map with initial soilwater content
Soilwater=soilwate; # reported maps with soilwater content (mm)
SoilwaterSurplus=soilsurp; # reported maps with soilwater surplus (mm)
Ldd=ldd.map; # local drain direction map
Discharge=dis; # runoff discharge (metres3/second)

74. Hydrological modelling
13 april 2017
Hydrological modelling
areamap
clone.map;
timer
1 12 1;
initial
# crop coefficients (k)
K=lookupscalar(CropCoeffTable,LandUse);
# initial soilwater content (mm)
Soilwater=InitSoilwater;
# maximum soilwater content (mm)
MaxSoilwater=scalar(400);
dynamic
report Precip=timeinputscalar(RainTimeSeries,RainAreas);
report VolumePrecip=maptotal(Precip)*(cellarea()/2628);
EvapRef=timeinputscalar(EvapRefTimeSeries,1);
report Evap=K*EvapRef;
report PrecipSurplus=Precip-Evap;
Soilwater=Soilwater+PrecipSurplus;
report SoilwaterSurplus=max(Soilwater-MaxSoilwater,0);
report Soilwater=min(Soilwater,MaxSoilwater);
DischargeMM=accuflux(Ldd,SoilwaterSurplus);
report Discharge=DischargeMM*(cellarea()/2628);

75. Hydrological modelling – real world examples
13 april 2017
Hydrological modelling – real world examples
Demo you have just seen
Not really a very useful model – but simple!
SAC-SMA
Distributed version of SAC-SMA concept
Linked to FEWS using General Adapter and PC Script see sacramento.mod
PCRGLOB
Distributed hydrological model at global scale, used for climate impact research
Dept. Physical Geography, Utrecht University
Linked to FEWS using General Adapter and PC Script see pcrglob_full_fews.mod

76. Linking PC Raster with FEWS
PCRaster has been linked to FEWS through two ways
Standard model adapter approach
PCRaster Model adapter
Applied for running models developed in PCRaster
Uses all standard model adapter functionality
Models can also be run “stand alone”outside FEWS
Integrated into Delft-Fews using in-memory XML link (pcrTransformation module)
Runs as a standard FEWS data transformation module
Applied for “complex” spatial data transformations
Can be used by everybody with a DelftFEWS license

77. Embedded link with FEWS
13 april 2017
Embedded link with FEWS
In memory XML based interface
Script “embedded” in FEWS
fews database
pcrTransformation
pcraster engine
pcrTransformation
fews database

78. Examples
Lapsing temperature to zero

79. Examples
PCRaster script

80. Filter radar data #! --unitcell dynamic
13 april 2017
Filter radar data
Input from FEWS – Radar gridded time series
#! --unitcell
dynamic
RADARunit = if(Radar > 0.0 then 1.0);
RF = windowtotal(RADARunit,2);
RFL = windowtotal(RADARunit,6);
RADARFILT = if(RF > 2 or RFL > 14 , Radar);
Return to FEWS – Filtered Radar gridded time series
Notes
This is a very simple filter! Better filters may be made using e.g. the clump operator
Unitcell means that the windowlength is defined in number of cells, otherwise use unittrue (default)

81. Filter radar data – raw data
13 april 2017
Filter radar data – raw data

82. Filter radar data – filtered data
13 april 2017
Filter radar data – filtered data

83. Real world example: PREVAH Model, Switzerland
13 april 2017
Real world example: PREVAH Model, Switzerland
A semi-distributed conceptual model (written in FORTRAN) linked to FEWS by GA
Post/Preoprocessing steps done using combination of PCRaster module and other transformations
Model concept based on hydrological response units

84. Real world example: PREVAH Model, Switzerland
Gridded data handling problem
Model domain discretised as Hydrological Response Units, combined with elevation zones: referred to as MeteoZones
Temperature input data from NWP model
Different resolution to model resolution
Orography in NWP model differs from orography in hydrological model as a result

85. Real world example: PREVAH Model, Switzerland
Emme Catchment to Wiler
(all forecasts :00 UTC)
Comparison of model orography
to NWP orography
NWP Temperature profiles compared
to observed interpolated profiles

86. Real world example: PREVAH Model, Switzerland
Processing of NWP Forecast temperatures.
Step 1: Lapse temperature to mean sea level using NWP elevation model
Step 2: Downscale lapsed temperatures from NWP grid resolution to Model resolution using bi-linear interpolation
Step 3: Lapse downscaled temperatures to PREVAH model elevation
Step 4: Sample temperature values per meteo-zone

87. Lapsing forecast temperature to mean sea level
Mean = 6.49 oC
std = oC
Mean = oC
std = 1.09 oC
NWP Forecast grid
Forecast T :00
TimeSlice: :00
Lapsed NWP Forecast grid
Forecast T :00
TimeSlice: :00

88. Resampling and lapsing to PREVAH Model Elevation

89. Average temperature per meteo-zone
Meteo Zones grid
Averaged per meteozone

90. Sample temperature time series per meteo-zone

91. PCRaster adapter Standard PCRaster adapter
Data passed to PCRaster through adapter (note that PCRaster grid format one of the three standard grid exchange formats)
Model run as in command line mode
Using PCRaster through Python
Recent development: PCRaster available as a Python Package
Model can be developed as in Python
Python scripts run through General adapter
requires Python libraries to read FEWS formatted I/O).
Some “research” adapters developed
PREVAH model adapter developed in Python
Offers many opportunities for rapid model development
Python-FEWS Package?
See
Example: WFLOW Model (research model at Deltares – Jaap Schellekens)

92. Questions…