Presentation is loading. Please wait.

Presentation is loading. Please wait.

Models and Modeling in FEWS Part I Micha Werner Deltares & UNESCO-IHE.

Similar presentations

Presentation on theme: "Models and Modeling in FEWS Part I Micha Werner Deltares & UNESCO-IHE."— Presentation transcript:

1 Models and Modeling in FEWS Part I Micha Werner Deltares & UNESCO-IHE

2 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 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 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 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 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 import external simulated

8 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-adapter run post-adapter run model run 1: Export model inputs 2: Run pre-adapter 3: Run model 4: Run post-adapter 5 Import model results

9 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 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 data 2D – longitudinal time series data

11 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 period Forecast 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 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 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 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 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 18 Lumped model Semi-distributed model Fully Distributed model From lumped to distributed

19 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 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 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 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 DistributedGrid2Grid WASIM-ETH PREVAH TOPKAPI Vflo REW* WFLOW* MODFLOW CEH-Wallingford ETH Zürich/Jürg Schulla WSL ProGea/Uni-Bologna Baxter Vieux Deltares Deltares & Adam Taylor England & Wales, Scotland Switzerland Italy, Spain Taiwan Research Applications England & Wales (NGMS)

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

24 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 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 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 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 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 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 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 31 Case Studies Integration of WASIM-ETH Workflow Relatively simple structure of workflow

32 32 Case Studies WASIM-ETH –Outputs returned to FEWS (currently) VariableParameter identifierUnitDescription Precipitation (snow)grid and scalarP.uh.snowmmPrecipitation on each grid cell in solid form Precipitation (rain)grid and scalarP.uh.rainmmPrecipitation on each grid cell in fluid form Runoff (direct)grid and scalarq.uh.dirmmDirect runoff from each cell Runoff (Interflow)grid and scalarq.uh.iflmmRunoff as interflow from each cell Runoff (baseflow)grid and scalarq.uh.basmmRunoff as baseflow from each cell Snow water Equivalentgrid and scalarSWE.uhmmSnow water equivalent in each grid cell Evapotranspirationgrid and scalarE.uh.etrmmEvaportranspiration from each grid cell Root Zone Moisture content grid and scalarRZM.uhmmSoil moisture content in the root zone for each grid cell Runoff (total)scalar onlyq.uh.basmmTotal runoff Discharge (total)scalar onlyQ.uhm3/sTotal discharge at each point (includes all runoff from upstream of that grid cell point)

33 33 Case Studies Snow water equivalent

34 34 Case Studies Direct runoff

35 35 Case Studies Interflow (unsaturated zone)

36 36 Case Studies Base flow

37 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 38 Comparison General impression: WASIM gives a better representation of the dynamic response of the catchment – but often oversimulates

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

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

41 41 HBV Emme-Egge ARMA Routing HBV Emme-Emme HBV Emme-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 42 Mixing models to utilize both advantages Simulation @ Emmematt Incremental flow @ Wiler Distributed model requires option to output incremental flow ARMA Routing ARMA Semi-distributed model Forecast @ Emmematt Forecast @ Wiler

43 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 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 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 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)

47 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 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 49 NHI (National Hydrological Instrument) The Netherlands → NHI (National Hydrological Instrument) Distribution Model (national surface water Δt=10d) Mozart (regional surf.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 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 51 FEWS-Water management output: ground water levels vs. climatology NHI (National Hydrological Instrument) The Netherlands Thanks to Peter Gijsbers for the slide

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

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

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

55 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 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 59 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 60 PCRaster PCRaster provides a simple environment with which dymanic spatial models can be build => Dynamic GIS environment Short demo (from PCRaster documentation)

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

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

63 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 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 InfiltrationCapacity=lookupscalar(SoilInfiltrationTable,SoilType);

65 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 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 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 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: = cover(,sqrt(9)) = cover(,sqrt(9))

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

70 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: = if(,,

71 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 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 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;# 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;# 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);# map with initial soilwater content Soilwater=soilwate;# reported maps with soilwater content (mm) SoilwaterSurplus=soilsurp;# reported maps with soilwater surplus (mm);# local drain direction map Discharge=dis;# runoff discharge (metres3/second)

74 74 Hydrological modelling areamap; 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 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.modsacramento.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.modpcrglob_full_fews.mod

76 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 77 Embedded link with FEWS In memory XML based interface Script “embedded” in FEWS pcraster engine pcrTransformation fews database pcrTransformation fews database

78 78 Examples Lapsing temperature to zero

79 79 Examples PCRaster script

80 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 81 Filter radar data – raw data

82 82 Filter radar data – filtered data

83 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 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 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

86 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 87 Lapsing forecast temperature to mean sea level NWP Forecast grid Forecast T0 05-05-2010 06:00 TimeSlice: 06-05-2010 14:00 Lapsed NWP Forecast grid Forecast T0 05-05-2010 06:00 TimeSlice: 06-05-2010 14:00 Mean = 6.49 o C std = 4.89 o C Mean = 15.05 o C std = 1.09 o C

88 88 Resampling and lapsing to PREVAH Model Elevation

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

90 90 Sample temperature time series per meteo-zone

91 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…

Download ppt "Models and Modeling in FEWS Part I Micha Werner Deltares & UNESCO-IHE."

Similar presentations

Ads by Google