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
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
  linkedtoDelft-Fews
• Generally the ownerof 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
0000
1200
1200
0000
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
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 NWS USACE CEH-Wallingford CEH-Wallingford SMHI DHI Don Carrol US US Po, Nile, etc England Wales, Scotland England Wales, Scotland Rhine (CH DE) England Wales, Spain, Po Mekong
Distributed Grid2Grid WASIM-ETH PREVAH TOPKAPI Vflo REW WFLOW MODFLOW CEH-Wallingford ETH Zürich/Jürg Schulla WSL ProGea/Uni-Bologna Baxter Vieux Deltares Deltares Deltares Adam Taylor England Wales, Scotland Switzerland Switzerland Italy, Spain Taiwan Research Applications 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)
Distributed Model (simulation)
State
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 (Richards/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

Model Inputs (all gridded)
Temperature
Precipitation
Vapour Pressure
Wind Speed
Global Radiation
Sunshine Duration
30
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)

Variable Parameter identifier Unit Description
Precipitation (snow) grid and scalar P.uh.snow mm Precipitation on each grid cell in solid form
Precipitation (rain) grid and scalar P.uh.rain mm Precipitation on each grid cell in fluid form
Runoff (direct) grid and scalar q.uh.dir mm Direct runoff from each cell
Runoff (Interflow) grid and scalar q.uh.ifl mm Runoff as interflow from each cell
Runoff (baseflow) grid and scalar q.uh.bas mm Runoff as baseflow from each cell
Snow water Equivalent grid and scalar SWE.uh mm Snow water equivalent in each grid cell
Evapotranspiration grid and scalar E.uh.etr mm Evaportranspiration from each grid cell
Root Zone Moisture content grid and scalar RZM.uh mm Soil moisture content in the root zone for each grid cell
Runoff (total) scalar only q.uh.bas mm Total runoff
Discharge (total) scalar only 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 _at_ Wiler
Forecast _at_ Emmematt
Routing
HBV Emme-Wiler
Forecast _at_ Emmematt
ARMA
Issue distributed model does not make use of
observed data in internal gauges
Forecast _at_ Wiler
42
Mixing models to utilize both advantages
Semi-distributed model
Simulation _at_ Emmematt
ARMA
Forecast _at_ Emmematt
Routing
Incremental flow _at_ Wiler
ARMA
Distributed model requires option to output
incremental flow
Forecast _at_ 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 APproximationandInt
  egration
• 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?pTOPKAPIcSof
twarelininglese
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 ?t10d
)
Meta-SWAP (sub-surface ?t1d)
Mozart (regional surf.wat. ?t10d)
demand/allocate
Demand/allocate
demand/ allocate
Modflow (national ground water model, ?t1d,
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
51
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

• FEWS-Water management output drought damage
  (fraction)

Thanks to Peter Gijsbers for the slide
53
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

• 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

• 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/)
• 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 . http//pcraster.geo.uu.nl/
• Download page http//pcraster.geo.uu.nl/downloads
  /

60
PCRaster

• PCRaster provides a simple environment with which
  dymanic spatial models can be build gt 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 http//pcraster.geo.uu.nl/docu
  mentation/Demo/DynamicModellingDemo.html

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 RainZonesspreadzone(Ra
inStations,0,1)
64
PCRaster Demo

• Variable infiltration map given soil properties

1 2.1 2 8.3 3 19.0
initial create an infiltration capacity map
(mm/6 hours), based on the soil map
InfiltrationCapacitylookupscalar(SoilInfiltration
Table,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 Lddlddcreate(Dem,1
e31,1e31,1e31,1e31)
66
PC Raster Demo

• Ready to run!!!

dynamic calculate and report maps with
rainfall at each timestep (mm/6 hours)
SurfaceWatertimeinputscalar(RainTimeSeries,RainZo
nes) compute both runoff and actual
infiltration RunoffPerTimestep,Infiltration
accuthresholdflux, accuthresholdstate(Ldd,SurfaceW
ater,InfiltrationCapacity) output runoff,
converted to m3/s, at each timestep report
RunOffRunoffPerTimestep/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
RunoffTimeSeriestimeoutput(SamplePlaces,RunOff)
68
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..

• 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..

• 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..

• 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

• Can be used for simple operations or to build
  (very) complex distributed hydrological models
• Many useful functions, see pcraster web-site

73
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 RainTimeSeriesrain12.tss
timeseries with rainfall (mm) per month
for two rain areas Preciprain reported
maps with precipitation, rain is suffix of
filenames RainAreasrainarea.map map with
two rain areas VolumePrecipvolrain.tss
reported timeseries with volume rain per
month (cubic metres per second)
CropCoeffTablecrcoefa.tbl column table with
crop coefficients for classes on LandUse
LandUselanduse.map map with nominal landuse
classes 1,2,3 EvapRefTimeSeriesevaref12.tss
timeseries with reference
evapotranspiration (mm) per month
PrecipSurplusrainsur maps with precipitation
surplus (mm/month) InitSoilwaterinitsw.map
map with initial soilwater content
Soilwatersoilwate reported maps with
soilwater content (mm) SoilwaterSurplussoilsurp
reported maps with soilwater surplus (mm)
Lddldd.map local drain direction map
Dischargedis runoff discharge
(metres3/second)
74
Hydrological modelling
areamap clone.map timer 1 12 1 initial
crop coefficients (k) Klookupscalar(CropCoeffTab
le,LandUse) initial soilwater content (mm)
SoilwaterInitSoilwater maximum soilwater
content (mm) MaxSoilwaterscalar(400) dynamic
report Preciptimeinputscalar(RainTimeSeries,RainA
reas) report VolumePrecipmaptotal(Precip)(cell
area()/2628) EvapReftimeinputscalar(EvapRefTim
eSeries,1) report EvapKEvapRef report
PrecipSurplusPrecip-Evap SoilwaterSoilwaterP
recipSurplus report SoilwaterSurplusmax(Soilwat
er-MaxSoilwater,0) report Soilwatermin(Soilwa
ter,MaxSoilwater) DischargeMMaccuflux(Ldd,Soil
waterSurplus) report DischargeDischargeMM(cell
area()/2628)
75
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
  Scriptsee 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
  Scriptsee 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 aloneoutside 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

• 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
Input from FEWS Radar gridded time series

• ! --unitcell
• dynamic
• RADARunit if(Radar gt 0.0 then 1.0)
• RF windowtotal(RADARunit,2)
• RFL windowtotal(RADARunit,6)
• RADARFILT if(RF gt 2 or RFL gt 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
82
Filter radar data filtered data
83
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 17-01-2010
0000 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 4.89 oC
Mean 15.05 oC std 1.09 oC
NWP Forecast grid Forecast T0 05-05-2010
0600 TimeSlice 06-05-2010 1400
Lapsed NWP Forecast grid Forecast T0 05-05-2010
0600 TimeSlice 06-05-2010 1400
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 http//pcraster.geo.uu.nl/documentation/PCRast
erPython/index.html Example WFLOW Model
(research model at Deltares Jaap Schellekens)
92
Questions