Upload
lukas
View
30
Download
3
Tags:
Embed Size (px)
DESCRIPTION
Models and Modeling in FEWS Part I. Micha Werner Deltares & UNESCO-IHE. 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 - PowerPoint PPT Presentation
Citation preview
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
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• import• validation• transformation / interpolation• data hierarchy• general adapter• export / report• administration (data, forecasts)• viewing (data, forecasts)• archiving• …
(forcing) data
models
export & dissemination
PI
imp
ort
external
simulated
8
General Adapter Module
Running models – how does it work
local datastore
FEWS
model
native files(e.g. txt)
native files(e.g. txt)
xml files(PI)
export
xml files(PI)
import
pre-adapterrun
post-adapterrun
model
run
1: Export model inputs2: Run pre-adapter3: Run model4: Run post-adapter5 Import model results
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
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
0D – point time series data
1D – longitudinal time series data2D – 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.
00:00 12:00 00:00 12:00
Start of forecast periodForecast period- Model requires inputs (forcing) across this period
Update run provides a state to start from (could also be default state by choice)
Model typically also “returns” state during forecast mode – but this will generally not be used
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)
Questions…
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
Lumped model Semi-distributed model
Fully Distributed 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) ModelHydrological 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
A. Physically based models will always provide better forecast results than conceptual models
• True
• False
24
Running a distributed model in a workflow
Import workflow
Export workflow
Example workflow
Fill gaps in precip & temp
Interpolate to model grid
Merge Grids
Run Distributed model
Run Routing Model
Principle is exactly the same as when running a lumped model
However, data processing steps may differ
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)
Interpolation
Observed meteo. variables
Distributed Model(simulation)
Interpolated (observed)
meteorological grids
Downscaling
Meteorological forecast grids
Distributed Model(simulation)
Downscaled meteorological grids
State
Update period Forecast 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 basinAs 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
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
WASIM(simulation)
Downscaled meteorological grids
Output grids & discharge (selected locations)
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) 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 secRun time (model run): 1 min 38 sec
HBV: 3 sub-basinsRun time (model run): 3 sec
• Database sizes can be considerable largerWASIM:
Input data processing: 3.5MBModel 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
Emme at Eggewil
0
20
40
60
80
100
120
0 10 20 30 40 50 60 70 80
observed flow (m3/s)
sim
ula
ted
flo
w (
m3/
s)
HBV
WASIM
y=x
39
Comparison of results from HBV and from WASIM at Eggewil and at Wiler
40
2.95
3.75
0.99
2.05
3.08
1.23
2160saribroc
2179senstoer
2215saanlaup
2085aarehagn
2019aarebrie
2109luetgest
2469kandhond
2151simmober
2135aarebern
2457AareringBrienzersee
2030AarethunThunersee
2409emmeeggi
2070emmeemme
2155emmewile
2471murgmurg
2063aaremurg
2016aarebrug
2450wiggzofi
2434duenolt
2091rheirhei
2378orbeorb
2480areuboud
2034broypaye
2447CanasugiMurtensee
2446ZihlgampNeuenburgersee
2029AarebrueBielersee
2.6
2.59
0.3
2.07
3.67
4.77
3.67
FEWS-CH: Schematisation and time lags of AARE
?
?
P,T
P,T
P,T
P,T Emme catchment• ARMA error correction at Emmemat & Wiler• Input correction ofr Emmemat & Egge sub-basins
41
HBVEmme-Egge
ARMA
Rou
ting
HBVEmme-Emme
HBVEmme-Wiler
ARMA
Semi-distributed model fully-distributed model
Forecast @ Emmematt
Forecast @ Wiler
Forecast @ Emmematt
Forecast @ Wiler
Issue: distributed model does not make use of observed data in internal gauges
42
Mixing models to utilize both advantages
Simulation @ Emmematt
Incremental flow @ Wiler
Distributed model requires option to output incremental flow
ARMA
Rou
ting
ARMA
Semi-distributed model
Forecast @ Emmematt
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 surfacewater
Δt=10d)
Mozart(regionalsurf.wat.Δt=10d)
Modflow(national ground water model, Δt=1d, 250x250m)
Meta-SWAP(sub-surface
Δt=1d)demand/allocate
demand/allocate
Demand/allocate
Thanks to Peter Gijsbers for the slide
50
Real time data feeds:
→ observations– meteo, sw, gw
→ forecasts– weather, river inflow
NHI (National Hydrological Instrument) The Netherlands
Thanks to Peter Gijsbers for the slide
51
FEWS-Water management output: ground water levels vs. climatology
NHI (National Hydrological Instrument) The Netherlands
Thanks to Peter Gijsbers for the slide
52
FEWS-Water management output: drought damage (fraction)
NHI (National Hydrological Instrument) The Netherlands
Thanks to Peter Gijsbers for the slide
53
FEWS-Water management output: surface water deficit
NHI (National Hydrological Instrument) The Netherlands
Thanks to Peter Gijsbers for the slide
54
National drought publication
NHI (National Hydrological Instrument) The Netherlands
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!
Questions…
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 => 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/documentation/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 RainZones=spreadzone(RainStations,0,1);
64
PCRaster Demo
Variable infiltration map given soil properties
1 2.12 8.33 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!!!
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..
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:
1. Catchment deliniating
2. Downstream routing of material
3. Calculating upstream area
4. 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 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 modellingareamap 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
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 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 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
• In memory XML based interface
• Script “embedded” in FEWS
pcraster engine
pcrTransformation
fews database
pcrTransformation
fews database
78
Examples
Lapsing temperature to zero
79
Examples
PCRaster script
80
Filter radar data
#! --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);
Input from FEWS – Radar gridded time series
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 00:00 UTC)
Comparison of model orography to NWP orography
NWP Temperature profiles compared to observed interpolated profiles
0 200 400 600 800 1000400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
Area (km2)
Ele
vatio
n (m
)
Area-Elevation
modelcosmo2
cosmo7
cosmo leps
ecmwfmax elevation
-15 -10 -5 0 5 10 15400
600
800
1000
1200
1400
1600
1800
2000
2200
2400
Temperature (degc)
Temperature-Elevation
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
NWP Forecast gridForecast T0 05-05-2010 06:00TimeSlice: 06-05-2010 14:00
Lapsed NWP Forecast gridForecast T0 05-05-2010 06:00TimeSlice: 06-05-2010 14:00
Mean = 6.49 oCstd = 4.89 oC Mean = 15.05 oC
std = 1.09 oC
88
Resampling and lapsing to PREVAH Model Elevation
89
Average temperature per meteo-zone
Meteo Zones gridAveraged 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/PCRasterPython/index.html
Example: WFLOW Model (research model at Deltares – Jaap Schellekens)
Questions…