User Tools

Site Tools


start:hype_tutorials:hype_setup_tutorial

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
start:hype_tutorials:hype_setup_tutorial [2015/06/29 17:34]
rcapell
start:hype_tutorials:hype_setup_tutorial [2024/01/25 11:37] (current)
Line 1: Line 1:
-====== Setting up a HYPE model domain - a beginner'​s tutorial ======+[[http://​example.com|External Link]]====== Setting up a HYPE model domain - a beginner'​s tutorial ======
  
 ===== Introduction ===== ===== Introduction =====
  
-This tutorial provides introductory guidelines for creating a new HYPE model set-up in a new model domain. These guidelines cover the creation and formatting of mandatory and optional input files for a basic HYPE rainfall-runoff and nutrient turnover model. HYPE requires all input datae.g. model domain information,​ observation data, or calibration parameters, as a set of formatted text files. All input files mentioned in this tutorial are documented in detail in the [[start:​hype_file_reference|file reference section]] of the HYPE documentation pages.+This tutorial provides introductory guidelines for creating a HYPE model set-up in a new model domain. These guidelines cover the creation and formatting of mandatory and optional input files for a basic HYPE rainfall-runoff and nutrient turnover model. HYPE requires all input data as a set of formatted text files (e.g. model domain information,​ observation data, or calibration parameters). All input files mentioned in this tutorial are documented in detail in the [[start:​hype_file_reference|file reference section]] of the HYPE documentation pages.
  
-HYPE domains are spatially divided into sub-basins for which hydrological response units (HRUs) are derived. In order to create a HYPE model set-up, modellers will have to create a suitable sub-basin delineation based on a topographical database. SMHI provides the freeware GIS tool [[http://hype.sourceforge.net/WHIST/|WHIST]] (World Hydrological Input Setup Tool) which is especially suited for setting up large HYPE domains ​using the [[http://​hydrosheds.cr.usgs.gov/​index.php|USGS'​s HYDROSheds Hydrologically conditioned elevation product]], but users can choose any GIS software suitable to derive sub-basins and flow routing connections and build their HYPE set-up workflow around them. WHIST provides additional functionality,​ e.g. to calculate HRU fractions for each sub-basin, and a convenient file export in HYPE-conform formatting. Many example figures in the tutorial text below show WHIST screenshots.+This tutorial is a minor part of the main tutorial for HYPE: [[https://​hypeweb.smhi.se/​model-water/​setting-up-hype/​|Setting-Up HYPE]] 
 + 
 +HYPE domains are spatially divided into sub-basins for which hydrological response units (HRUs) are derived. In order to create a HYPE model set-up, modellers will have to create a suitable sub-basin delineation based on a topographical database. SMHI provides the freeware GIS tool [[https://git.smhi.se/whist/​whist/​-/​wikis/​home/|WHIST]] (World Hydrological Input Setup Tool) which is especially suited for setting up large HYPE domains. ​WHIST provides additional functionality,​ e.gto calculate HRU fractions for each sub-basinand a convenient file export in HYPE-conform formatting ​but users can choose any GIS software suitable to derive sub-basins and flow routing connections and build their HYPE set-up workflow around them.  
  
 The following links list further in-depth reading, complementary to this tutorial: The following links list further in-depth reading, complementary to this tutorial:
  
-  * The [[start:​hype_tutorials:​short_intro|Quick Guide]] gives an introduction to mandatory files and important parameters of a basic HYPE set-up 
   * The [[start:​hype_model_description|HYPE model description]] documents all process conceptualisations used in HYPE   * The [[start:​hype_model_description|HYPE model description]] documents all process conceptualisations used in HYPE
   * The [[start:​hype_file_reference|HYPE file reference]] provides a technical reference to all HYPE files, parameters and variables   * The [[start:​hype_file_reference|HYPE file reference]] provides a technical reference to all HYPE files, parameters and variables
Line 15: Line 16:
 HYPE software is available from the following sites: HYPE software is available from the following sites:
   * HYPE model code including precompiled windows executables and updated information on latest developments a hosted on the [[http://​hype.sourceforge.net/​|HYPE Open Source Community Pages]]   * HYPE model code including precompiled windows executables and updated information on latest developments a hosted on the [[http://​hype.sourceforge.net/​|HYPE Open Source Community Pages]]
-  ​* The above-mentioned GIS tool set WHIST including manual is also hosted as a part of the [[http://​hype.sourceforge.net/​WHIST/​|HYPE Open Source Community Pages]] +  * [[https://​github.com/​rcapell/​HYPEtools/|HYPEtools]] is an add-on package for the [[http://​www.r-project.org/​|R software environment]] to pre- and post-process HYPE data and support analysis of model results ​in RSee installation ​instructions [[https://​github.com/​rcapell/​HYPEtools/​wiki/​Install-and-Update-HYPEtools-from-github|here]]
-  ​* [[https://​github.com/​rcapell/​RHYPE/|RHYPE]] is an add-on package for the [[http://​www.r-project.org/​|R software environment]] to pre- and post-process HYPE data and support analysis of model results. ​Installation ​instructions ​are written ​[[https://​github.com/​rcapell/​RHYPE/​wiki/​Install-and-Update-RHYPE-from-github|here]]+
  
  
Line 23: Line 23:
 If sub-basins do not exist for the targeted model domain, or if the routing is not defined between them, this information has to be created for a HYPE model set-up. If sub-basins do not exist for the targeted model domain, or if the routing is not defined between them, this information has to be created for a HYPE model set-up.
  
-SMHI has developed a software for this purpose called WHIST, see links aboveThe manual “Procedure for using WHIST” describes step by step how to create hydrologically ​connected ​subbasins and how to extract information needed as input for the HYPE model. ​The software can also import already delineated subbasins from shapefile with or without routing information.+SMHI has, as already mentioned, ​developed a software for this purpose called ​[[https://​git.smhi.se/​whist/​whist/​-/​wikis/​home|WHIST]]Besides the [[https://​git.smhi.se/​whist/​whist/​-/​wikis/​WHIST-Wiki/​-3.-Download-software-and-get-started|software]] the WHIST pages include descriptions on how to [[https://​git.smhi.se/​whist/​whist/​-/​wikis/​WHIST-Wiki/​Create-subbasins-from-hydrologically-corrected-topography-data-(DEM,​-DIR,​-ACC)|create ​subbasins]] from hydrologically ​corrected topography data, [[https://​git.smhi.se/​whist/​whist/​-/​wikis/​WHIST-Wiki/​Import-subbasin-polygons-with-or-without-existing-routing-information|import already existing ​subbasins]], [[https://​git.smhi.se/​whist/​whist/​-/​wikis/​WHIST-Wiki/​11.-Extract-and-connect-attributes-to-the-subbasins|extract ​spatial ​information]] for each subbasin ​needed as input for the HYPE model and [[https://​git.smhi.se/​whist/​whist/​-/​wikis/​WHIST-Wiki/​12.-Export-shapefiles-and-tables|export]] of shapefiles of the created subbasin polygons and [[http://​www.smhi.net/​hype/​wiki/​doku.php?​id=start:​hype_file_reference:​geodata.txt|GeoData]] file in HYPE format. A basic model and some exercises are also provided to get started and used to the WHIST interface.
  
 The following sections outline the main steps which need to be taken to create a HYPE set-up in a new model domain. The following sections outline the main steps which need to be taken to create a HYPE set-up in a new model domain.
  
  
-==== Routinglakes, soil and landuse ​====+==== Subbasinsrouting ​and forced points ​====
  
-HYPE model domains are divided into spatially delineated sub-basins. A hydrologically corrected gridded topographic database is used to derive the model domain (i.e. all sub-basin areas). The procedure is controlled by the geographic location of gauging stations and their documented catchment area which should ​have been quality checked ​before the delineation ​of the subbasins since the outlet ​of the developed subbasins should ​be drawn to fit the position of the gauging ​stations to get the best simulation conditions ​and optimize ​the possibilities ​to calibrate the model, see Fig. 1 to Fig. 3. How big these adjustments are is dependent on the resolution of the elevation data.+HYPE model domains are divided into spatially delineated sub-basins. A hydrologically corrected gridded topographic database is used to derive the model domain (i.e. all sub-basin areas). The procedure is preferably ​controlled by the geographic location of gauging stations ​(so called "​forced points"​) ​and their documented catchment area. Before use, especially when using larger global databases, all data used should ​be quality checked ​and gauging stations used as forced points during ​delineation ​need to be adjusted to the river network ​of the used topography data. The delineation can then be forced ​to capture ​the gauging ​station at the subbasin outlet ​and then the possibility ​to calibrate the model against the observations is optimized, see Fig. 1 to Fig. 3. How big the adjustments are is dependent on the resolution of the elevation data and the quality of the gauging station metadata.
  
 |{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure1.png?​direct&​700 |}}| |{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure1.png?​direct&​700 |}}|
Line 41: Line 41:
 |//Figure 3: The subbasin border is drawn to fit the outlet to the gauging station.//| |//Figure 3: The subbasin border is drawn to fit the outlet to the gauging station.//|
  
-Each subbasin must receive a unique subbasin ID (SUBID) and the SUBID of the subbasin next downstream to explain the routing, see figure 4. This is mandatory for the model and described in geodata.txt(länka till stycket längre ned i detta document)+Each subbasin must receive a unique subbasin ID (SUBID) and the SUBID of the subbasin next downstream ​(called MAINDOWN in HYPE) to explain the routing, see figure 4. This is mandatory for the model and described in GeoData.txt (more info [[start:​hype_tutorials:​hype_setup_tutorial#​input_data_geodatatxt|here]]).
  
 |{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure4.png?​direct&​700 |}}| |{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure4.png?​direct&​700 |}}|
 |//Figure 4: Routing between sub-basins. SUBID 103 is next downstream to SUBID 102. SUBID 102 is next downstream to SUBID 101 and 104.//| |//Figure 4: Routing between sub-basins. SUBID 103 is next downstream to SUBID 102. SUBID 102 is next downstream to SUBID 101 and 104.//|
  
-To describe the landuse and soil properties for each subbasin in the model, these are combined into so called SLC (Soil and Landuse Classes) classes (for example forest + medium soils, open land + fine soils etc), see figure 5. The distribution of SLC classes for each subbasin is described in geodata.txt and the SLC classes are defined in geoclass.txt (länka till stycket längre ned i detta document). ​ 
  
-Keep landuse and soil classes essential and typical for the model domain but merge classes into a number you will manage to calibrate. 
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure5.png?​direct&​700 |}}| 
-|//Figure 5: Soil and landuse information is combined into SLC classes. Each subbasin is described with the proportion of the different classes in GeoData.txt.//​| 
  
-Lakes can be included to the model in two ways: as local lakes (ilakes) or as outlet lakes (olakes), see figure ​6. The outlet lakes can be provided with rating curves and/or regulation schemes in lakedata.txt(Länka till stycket längre ned i detta documentThe outlet lakes could be inserted as subbasins with their outlets corresponding to the subbasin outlet, see figure 7.+==== Lakes ==== 
 + 
 +Lakes can be included to the model in two ways: as local lakes (ilakes) or as outlet lakes (olakes) ​located at the main stream and at the outlet of a subbasin, see figure ​5. The outlet lakes can be provided with individual ​rating curves and/or regulation schemes in LakeData.txt (more info [[start:​hype_tutorials:​hype_setup_tutorial#​information_about_outlet_lakes_lakedatatxt|here]]). 
  
 |{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure6.png?​direct&​300 |}}| |{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure6.png?​direct&​300 |}}|
-|//​Figure ​6: Description of outlet lakes (o) and local lakes (i).//|+|//​Figure ​5: Description of outlet lakes (o) and local lakes (i).//|
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure7.png?​direct&​700 |}}| +The outlet lake can be modelled as a part of a subbasin (located at the subbasin ​outlet), as an individual subbasin ​(100 % lake) or as a so called Multibasin lake which covers several subbasins (but still with its outlet corresponding ​to the most downstream ​subbasin ​outlet), see figure 6. Multibasin lakes must be described in LakeData.txt to be correct represented. The two other types can either just have general parameters in the par.txt file or individual parameters in the LakeData.txt.
-|//Figure 7: Sub-basins should ​be drawn with their outlets fitting to the olakes ​outlet. The olake could either be an individual subbasin or included ​to the upstream ​subbasin.//|+
  
 +| {{ :​start:​hype_tutorials:​hype_setup_tutorial:​olakes.png?​700&​direct }}                                                                                                                                                                                                                                                                                                             |
 +| //Figure 6: Sub-basins should be drawn with their outlets fitting to the olakes outlet. The olake could either be totally within a larger ​ subbasin (no need of exact shape of olake) drawn as its own subbasin (lake polygon needed) ​ or cover several subbasins (multibasin olake). For all types of olakes the outlet of the lake should coincide with the subbasin outlet.// ​ |
  
-==== Climate Data ====+Regardless of which outlet lake representation to choose it is necessary to use the (o-)lake outlet points as  forced points when generating the subbasins. 
 +  
 + 
 +===== Soil and landuse characteristics ===== 
 + 
 +Hydrological response units (HRUs) are derived for each subbasin. In HYPE the soil and landcover properties are  combined into so called SLC's, Soil and Landcover Classes (for example forest + medium soils, open land + fine soils etc), see figure 7. The distribution of SLC classes for each subbasin is described in GeoData.txt and the SLC classes are defined in GeoClass.txt ​ (more info [[start:​hype_tutorials:​hype_setup_tutorial#​input_data_geoclasstxt|here]]). 
 + 
 +Keep landuse and soil classes essential and typical for the model domain but merge classes into a number you will manage to calibrate.  
 + 
 +|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​slc.png?​direct&​700 |}}| 
 +|//Figure 7: Soil and landuse information is combined into SLC classes. Each subbasin is described with the proportion of the different classes in GeoData.txt.//​| 
 + 
 +===== Climate Data =====
  
 The model is forced by temperature ([[start:​hype_tutorials:​hype_setup_tutorial#​input_data_p_obs_t_obs_forckey|Tobs.txt]]) and precipitation ([[start:​hype_tutorials:​hype_setup_tutorial#​input_data_p_obs_t_obs_forckey|Pobs.txt]]) time series (mandatory) as a minimum. Temperature and precipitation can be corrected by elevation. The mean elevation of each sub-basin is included to the [[start:​hype_file_reference:​geodata.txt|GeoData.txt]] file.  The model is forced by temperature ([[start:​hype_tutorials:​hype_setup_tutorial#​input_data_p_obs_t_obs_forckey|Tobs.txt]]) and precipitation ([[start:​hype_tutorials:​hype_setup_tutorial#​input_data_p_obs_t_obs_forckey|Pobs.txt]]) time series (mandatory) as a minimum. Temperature and precipitation can be corrected by elevation. The mean elevation of each sub-basin is included to the [[start:​hype_file_reference:​geodata.txt|GeoData.txt]] file. 
Line 72: Line 83:
 Read more about these processes [[start:​hype_model_description:​hype_land&#​snow_routines| in the model description]]. Read more about these processes [[start:​hype_model_description:​hype_land&#​snow_routines| in the model description]].
  
-The model could use different types of PET (potential evaporation) models (http://​www.smhi.net/​hype/​wiki/​doku.php?​id=start:​hype_model_description:​processes_above_ground#​alternative_potential_evaporation_models). The different options for calculation of potential evapotranspiration requires additional forcing data, e.g. potential evaporation,​ extra-terrestrial radiation, daily min and max air temperatures,​ shortwave radiation, relative humidity, wind speed. ​+The model could use different types of PET (potential evaporation) models ([[http://​www.smhi.net/​hype/​wiki/​doku.php?​id=start:​hype_model_description:​processes_above_ground#​alternative_potential_evaporation_models|Alternative potential evaporation models]]). The different options for calculation of potential evapotranspiration requires additional forcing data, e.g. potential evaporation,​ extra-terrestrial radiation, daily min and max air temperatures,​ shortwave radiation, relative humidity, wind speed. ​
  
 The HYPE code is continuously under development and new opportunities to force the model may be developed in the future. See http://​hype.sourceforge.net/ ​ for news. The HYPE code is continuously under development and new opportunities to force the model may be developed in the future. See http://​hype.sourceforge.net/ ​ for news.
  
-==== Modelling water quality ====+===== Modelling water quality ​=====
  
 There is an option to run water quality with HYPE.  There is an option to run water quality with HYPE. 
Line 94: Line 105:
 All input files to HYPE are listed and described in detail in the [[start:​hype_file_reference#​hype_file_reference|HYPE file reference]] section of the online documentation. All input files to HYPE are listed and described in detail in the [[start:​hype_file_reference#​hype_file_reference|HYPE file reference]] section of the online documentation.
  
-Some of the setup and input data files described in this section of the tutorial are mandatory for every HYPE model setup: ​GeoClass.txt, GeoData.txt, Tobs.txt, Pobs.txt, info.txt, par.txt.+Some of the setup and input data files described in this section of the tutorial are mandatory for every HYPE model setup: ​[[http://​www.smhi.net/​hype/​wiki/​doku.php?​id=start:​hype_tutorials:​short_intro#​mandatory_input_data|Mandatory input data]]
  
-Error checking is very limited, so be careful to follow the described file formats.+Always ​be careful to follow the described file formats.
  
  
 ==== Input data, GeoClass.txt ==== ==== Input data, GeoClass.txt ====
  
-[[start:​hype_file_reference:​geoclass.txt|GeoClass.txt]] is a file that defines the properties of the Soil and Landuse Classes (SLC) in geodata. ​It also describes special classes (lakes and glaciers)the number ​and depths ​of the soil layers.+[[start:​hype_file_reference:​geoclass.txt|GeoClass.txt]] is a file that defines the properties of the Soil and Landuse Classes (SLC) in geodata. ​Each class also need information about stream drainage depth, number of soil layers ​and soillayer thickness. Special classes as outlet lakes, local lakes, glaciers are defined and if nutrient will be simulated also crop type is necessary to define.
  
-Figure 8 shows a typical GeoClass.txt file. The first three rows contain comments, here some class ID references for different columns. These rows are denoted with an exclamation mark “!”. The column heads on row 4 are also just comments and not necessary for HYPE since the order of columns is predefined. The first column describes the SLC id. This id links geoclass to the SLC information in geodata.txt. The second and third column describes the combination of landuse and soil in the SLC. Lakes (here: SLC 1 and 2) have 2 rows here. One for the special class 1 (outlet lake) and one for the special class 2 (internal lake). Glaciers also have a figure (3) in the special class column. All classes have got a figure for the vegetation type. This is only used for the NP simulations though. Crops have got a tile-depth in this example. It describe the distance from soil surface to the tile drainage system. Drain depth is the distance from soil surface to local stream depth. The last 4 columns describe the number of soil layers and the depth of these layers from soil surface to bottom of each soil layer+Figure 8 shows a typical GeoClass.txt file. The first three rows contain comments, here some class ID references for different columns. These rows are denoted with an exclamation mark “!”. The column heads on row 4 are also just comments and not necessary for HYPE since the order of columns is predefined. ​
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure8.png?​direct&​700 |}}|+The first column describes the SLC id. This id links geoclass to the SLC information in GeoData.txt. The second and third column describes the combination of landuse and soil in the SLC. Lakes (here: SLC 1 and 2) have 2 rows here. One for the special class 1 (outlet lake) and one for the special class 2 (internal lake). Glaciers also have a figure (3) in the special class column.  
 + 
 +All classes have got a figure for the vegetation type. This is only used for the NP simulations though. Crops have got a tile-depth in this example. It describe the distance from soil surface to the tile drainage system. Drain depth is the distance from soil surface to local stream depth.  
 + 
 +The last 4 columns describe the number of soil layers and the depth of these layers from soil surface to bottom of each soil layer.  
 + 
 +|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​geoclass.png?​direct&​700 |}}|
 |//Figure 8: Typical GeoClass.txt structure.//​| |//Figure 8: Typical GeoClass.txt structure.//​|
  
 ==== Input data, GeoData.txt ==== ==== Input data, GeoData.txt ====
  
-Geodata.txt holds information about the subbasins, i.e. routingarea, mean elevation, ​fraction ​of SLCsparameter regions, general lake depths etc. See [[start:​hype_file_reference:​geodata.txt|GeoData.txt]] for a comprehensive reference on GeoData.txt columns.+Geodata.txt holds information about the subbasins. One subbasin on each row. Necessary information is an identification number (subid), subbasin area (area), and area fractions of different classes (slc_nn). Other information that is often included in GeoData.txt is the routing, i.e. subid of downstream subbasin (maindown)main river length (rivlen), mean elevation ​(elev_mean) and outlet lake average depth (lake_depth). For nutrient simulations also crop region (region)atmospheric deposition (e.g. precipitation concentration ​of inorganic nitrogenwetdep_n) and diffuse sources from rural households are common. See [[start:​hype_file_reference:​geodata.txt|GeoData.txt]] for a comprehensive reference on GeoData.txt columns
 + 
 +The structure of a GeoData.txt files is shown in Fig. 9. The first column holds the ROWNR to keep the order of the rows since the subbasins have to be ordered in a downstream sequence starting at headwaters and ending at outlet basins. The columns SUBID and MAINDOWN (0=outlet to the sea) hold the routing information (see the yellow marked cells for an example of how the routing is given)
  
-The structure of a GeoData.txt files is shown in Fig. 9. The first column holds the ROWNR to keep the order of the rows since the subbasins have to be ordered in a downstream sequence starting at headwaters and ending at outlet basins. The columns SUBID and MAINDOWN (0=outlet to the sea) hold the routing information (see green cells). ​The columns may be in any order. The mandatory columns ​for simulating water are: SUBID, MAINDOWN, AREA, ICATCH, RIVLEN and SLC_nn, but it is also recommended to use LAKE_DEPTH and ELEV_MEAN. If you use a [[start:​hype_file_reference:​lakedata.txt|LakeData.txt]] file for tailored data on lake properties, you need to link to this file in the column named LAKEDATAID (see blue cell). ​The parameter regions ​(which ​can be used in par.txt  ​to correct some parameters according ​to regions) ​are described in PARREG column. The sum of the SLCs should always be =1. See the geodata.txt for more information about the geodata ​columns.+The columns may be in any order and the sum of the SLCs for each subbasin should be =1. If your model contain ​a [[start:​hype_file_reference:​lakedata.txt|LakeData.txt]] file for tailored data on lake properties, you need to link to this file in the column named LAKEDATAID (see blue cell). ​HAROID ​(main river basin ID) is not mandatory but if your model cover many river basins it is handsome to see which subbasins belong to which main river basinUPAREA (the total upstream area of the subbasin) is not mandatory either, but also useful ​to easily see if it is a large or small area contributing ​to the actual subbasin. HAROID and UPAREA ​are exported from WHIST by default. See the [[start:​hype_file_reference:​geodata.txt|GeoData.txt]] ​for more information about the GeoData ​columns.
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure9.png?​direct&​700 |}}|+|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​geodata.png?​direct&​700 |}}|
 |//Figure 9: An example of GeoData.txt file structure.//​| |//Figure 9: An example of GeoData.txt file structure.//​|
  
-It is necessary that the subbasins are ordered in a downstream sequence. [[https://​github.com/​rcapell/​RHYPE/|RHYPE]] includes a function //​SortGeoData()//​ for this purpose.+It is necessary that the subbasins are ordered in a downstream sequence. [[https://​github.com/​rcapell/​HYPEtools/|HYPEtools]] includes a function //​SortGeoData()//​ for this purpose.
  
-When GeoData.txt has been constructed it is always ​agood idea to check the tailoring of the data. Join the geodata.txt to the subbasin shapefile and produce some maps for spatial check, ​ i.e. ELEV_MEAN, summerized LandUse and Soilclasses. ​ A function //​GroupSLCClasses()//​ from RHYPE can be helpful. To check the routing you can map each sub-basin'​s catchment area (from WHIST: AREA+UPAREA,​ from RHYPE: //​SumUpstreamArea()//​) and get a view of the network. ​+When GeoData.txt has been constructed it is always ​a good idea to check the tailoring of the data. Join the GeoData.txt to the subbasin shapefile and produce some maps for spatial check, ​ i.e. ELEV_MEAN, summerized LandUse and Soilclasses. ​ A function //​GroupSLCClasses()//​ from HYPEtools ​can be helpful. To check the routing you can map each sub-basin'​s catchment area (from WHIST: AREA+UPAREA,​ from HYPEtools: //​SumUpstreamArea()//​) and get a view of the network. ​
  
-==== Input data, P(obs), T(obs), ​Forckey ​====+==== Input data, P(obs), T(obs), ​ForcKey ​====
  
 Precipitation (mm/time step) and temperature time series (°C/time step) are needed to force the model. [[start:​hype_file_reference:​pobs.txt|Pobs.txt]] and [[start:​hype_file_reference:​tobs.txt|Tobs.txt]] files are therefore mandatory. ​ If you use complementary data needed for other PET/​snowfall/​snowmelt models other than standard, these options can be chosen in info.txt, see [[start:​hype_file_reference:​info.txt#​model_options|model options]]. Precipitation (mm/time step) and temperature time series (°C/time step) are needed to force the model. [[start:​hype_file_reference:​pobs.txt|Pobs.txt]] and [[start:​hype_file_reference:​tobs.txt|Tobs.txt]] files are therefore mandatory. ​ If you use complementary data needed for other PET/​snowfall/​snowmelt models other than standard, these options can be chosen in info.txt, see [[start:​hype_file_reference:​info.txt#​model_options|model options]].
Line 136: Line 155:
  
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure10.png?​direct&​400 |}}|+|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​pobs.png?​direct&​400 |}}|
 |//Figure 10: Part of Pobs.txt. First column is used for dates, following columns for observed data. Column headers are either SUBID (if you have a unique observation for each SUBID) or POBSID (if you use ForcKey.txt and several SUBIDs use the same time series).//| |//Figure 10: Part of Pobs.txt. First column is used for dates, following columns for observed data. Column headers are either SUBID (if you have a unique observation for each SUBID) or POBSID (if you use ForcKey.txt and several SUBIDs use the same time series).//|
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure11.png?​direct&​400 |}}|+|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​tobs.png?​direct&​400 |}}|
 |//Figure 11: Part of Tobs.txt. First column is used for dates, following columns for observed data. Column headers are either SUBID (if you have a unique observation for each SUBID) or TOBSID (if you use ForcKey.txt and several SUBIDs use the same time series).//| |//Figure 11: Part of Tobs.txt. First column is used for dates, following columns for observed data. Column headers are either SUBID (if you have a unique observation for each SUBID) or TOBSID (if you use ForcKey.txt and several SUBIDs use the same time series).//|
  
Line 155: Line 174:
 === ForcKey === === ForcKey ===
  
-ForcKey.txt is a key file for linking forcing data ID to SUBID. This file is not necessary if SUBIDs are used in Pobs.txt and Tobs.txt. If ForcKey.txt is used, this has to be stated in the info.txt with //readobsid = y//.+ForcKey.txt is a key file for linking forcing data ID to SUBID. This file is not necessary if SUBIDs are used in Pobs.txt and Tobs.txt. If ForcKey.txt is used, this has to be stated in the info.txt with //readobsid = y//. If several subbasins are linked to the same Pobs and Tobs time series (e.g. if the resolution of the forcing data is coarser than the average size of the subbasins) the use of a ForcKey file can decrease the size of the Pobs and Tobs files and then also the running time of the model.
  
 The structure of a typical ForcKey.txt file can be seen in Fig. 12. The structure of a typical ForcKey.txt file can be seen in Fig. 12.
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure12.png?direct&350 |}}| +| {{ :​start:​hype_tutorials:​hype_setup_tutorial:​forckey.png?350&direct }}                                                                                                                                                                                                                                             ​
-|//Figure 12: Example of ForcKey.txt. The first column describes the SUBID. The next column the elevation for air temperature observation in meter. The third and fourth columns show the TOBSID and POBSID used in Pobs.txt and Tobs.txt.//​|+| //Figure 12: Example of ForcKey.txt. The first column describes the SUBID. The next column the elevation for air temperature observation in meter. The third and fourth columns show the TOBSID and POBSID used in Pobs.txt and Tobs.txt. Here the last two subbasins are linked to the same POBSID and TOBSID.//  |
  
  
Line 171: Line 190:
 For different type of output files see the [[start:​hype_file_reference#​output_files|file reference entries for output files]]. For different types of output variables see the [[start:​hype_file_reference:​info.txt:​variables|file reference entries for output variables]]. For different type of output files see the [[start:​hype_file_reference#​output_files|file reference entries for output files]]. For different types of output variables see the [[start:​hype_file_reference:​info.txt:​variables|file reference entries for output variables]].
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure13.png?​direct&​700 |}}|+|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​info.png?​direct&​700 |}}|
 |//Figure 13 (click to enlarge): info.txt example structure. ​ Marked in red are [[start:​hype_file_reference:​info.txt&#​model_options|codes to set model options]], which are typically followed by [[start:​hype_file_reference:​info.txt#​output_options| codes describing output options]] (marked in green), and [[start:​hype_file_reference:​info.txt#​performance_criteria_options| codes describing performance criteria options]].//​| |//Figure 13 (click to enlarge): info.txt example structure. ​ Marked in red are [[start:​hype_file_reference:​info.txt&#​model_options|codes to set model options]], which are typically followed by [[start:​hype_file_reference:​info.txt#​output_options| codes describing output options]] (marked in green), and [[start:​hype_file_reference:​info.txt#​performance_criteria_options| codes describing performance criteria options]].//​|
  
Line 178: Line 197:
  
 The parameter file, par.txt, hold model parameters some of which can be calibrated. The parameter file, par.txt, hold model parameters some of which can be calibrated.
-Some parameters are general, ​ some landuse dependent, some soil dependent. There are also some parameters that can be tailored to certain given regions. See further information in the [[start:​hype_file_reference:​par.txt|file reference entry for par.txt]]. There are also some suggestions on start values in the [[start:​hype_tutorials:​short_intro#​basic_model_parameters|Quick Guide tutorial]].+Some parameters are general, ​ some landuse dependent, some soil dependent. There are also some parameters that can be tailored to certain given regions. See further information in the [[start:​hype_file_reference:​par.txt|file reference entry for par.txt]]. There are also some suggestions on start values in the [[http://​www.smhi.net/​hype/​wiki/​doku.php?​id=start:​hype_tutorials:​short_intro#​eleven_basic_model_parameters|Quick Guide tutorial]].
  
-A simple example of the structure of the par.txt is described in Fig. 14. Parameters are soil-, landuse- or region-dependent. There are also general parameters used for the total model domain. Parameters dependent on soil and landuse classes have to be ordered in the same way as in the GeoClass.txt file. Region-dependent parameters are parameters which collectively alter groups of parameters and allow for regional tuning (super-parameters). Parameter regions for these have to be defined in GeoData.txt in a column named PARREG.+A simple example of the structure of the par.txt is described in Fig. 14. Parameters are soil-, landuse- or region-dependent. There are also general parameters used for the total model domain. Parameters dependent on soil and landuse classes have to be ordered in the same way as in the GeoClass.txt file. As you can see the par.txt file example in Fig 14 has the same number of landuse and soil parameters as described in the GeoClass file in Fig. 8. Region-dependent parameters are parameters which collectively alter groups of parameters and allow for regional tuning (super-parameters). Parameter regions for these have to be defined in GeoData.txt in a column named PARREG.
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure14.png?direct&400 |}}| +| {{ :​start:​hype_tutorials:​hype_setup_tutorial:​par.png?400&​direct ​}}                                                             ​
-|//Figure 14: A basic example of par.txt. One row per parameter. Comment rows can be inserted using '​!!'​.//​|+| //Figure 14: A basic example of par.txt ​(click to enlarge). One row per parameter. Comment rows can be inserted using '​!!'​.// ​ |
  
  
 ===== Setting up optional input files for HYPE ===== ===== Setting up optional input files for HYPE =====
  
-There are many optional components in HYPE. Below we describe some of the most commonly used optional model components, lakes and reservoirs and bifurcations,​ which often have large impact on the hydrology in large-scale river basins.+There are many optional components in HYPE. Below we describe some of the most commonly used optional model components, lakes and reservoirs and bifurcations,​ which often have large impact on the hydrology in large-scale river basins. Others can be found among the tutorials (e.g. [[start:​hype_tutorials:​floodplain_tutorial|floodplains]]).
 ==== Information about outlet lakes (LakeData.txt)==== ==== Information about outlet lakes (LakeData.txt)====
  
Line 195: Line 214:
 === Suggested procedure === === Suggested procedure ===
  
-  * Link the outlet lakes to the SUBID’s ​of your model. +  * Link the outlet lakes to the SUBIDs ​of your model. 
-  * Complete ​lakedata.txt, see Fig. 15, with lake depths, outlet curves, regulation volumes, regulation routines, etc. where available. Use default depth for lakes where data is not available. A lot of information can be found on internet.  +  * Complete ​LakeData.txt, see Fig. 15, with lake depths, outlet curves, regulation volumes, regulation routines, etc. where available. Use default depth for lakes where data is not available. A lot of information can be found on internet. 
-  * Geodata.txt must have a link to lakedata.txt. The column ​lakadataid” is used in both geodata.txt and lakedata.txt for this purpose.+  * Give the lakes and multibasin lakes correct ldtype. 
 +  * Give all the parts of a multibasin lakes the same lakeid to show that they are belonging to the same lake.  
 +  * GeoData.txt must have a link to LakeData.txt. The column ​''​lakadataid'' ​is used in both GeoData.txt and LakeData.txt for this purpose.
   * Calibrate outlet curves and regulation routines for lakes with gauging stations near the outlet (i.e. run HYPE)   * Calibrate outlet curves and regulation routines for lakes with gauging stations near the outlet (i.e. run HYPE)
   * General rating curves or regulation routines may be possible to use for different regions or reservoirs for different purposes if no discharge data or water level data is available.   * General rating curves or regulation routines may be possible to use for different regions or reservoirs for different purposes if no discharge data or water level data is available.
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure15.png?​direct&​700 |}}| +|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​lakedata.png?​direct&​700 |}}| 
-|//Figure 15 (click to enlarge): Example of LakeData.txt. The LakeDataID is the link between GeoData.txt and LakeData.txt files. If a SUBID has a LakeDataID in GeoData.txt,​ the olake in this SUBID will be calculated according to the information in LakeData.txt. Black rows show some typical lakes, blue rows shows an example how to set up a multi-basin lake. The first blue row (boldsummerizes all basins. The red rows show some typical reservoirs. See more information about this file in [[start:​hype_file_reference:​lakedata.txt|Lakedata.txt]].//|+|//Figure 15 (click to enlarge): Example of LakeData.txt. The LakeDataID is the link between GeoData.txt and LakeData.txt files. If a SUBID has a LakeDataID in GeoData.txt,​ the olake in this SUBID will be calculated according to the information in LakeData.txt. Black rows show some typical lakes, blue rows shows an example how to set up a multi-basin lake. The last blue row (also the outlet of the olake), keeps the rating and regulation parameters for the entire lake. The red rows show some typical reservoirs. See more information about this file in [[start:​hype_file_reference:​lakedata.txt|LakeData.txt]].//|
  
  
 ==== Bifurcations (BranchData.txt) ==== ==== Bifurcations (BranchData.txt) ====
  
-With this file it is possible to describe bifurcations and other water diversions in downstream direction. Read more about this file in [[start:​hype_file_reference:​branchdata.txt|Branchdata.txt]]. Fig. 16 provides an example of a BranchData.txt file. +With this file it is possible to describe bifurcations and other water diversions in downstream direction. Read more about this file at [[start:​hype_file_reference:​branchdata.txt|BranchData.txt]]. Fig. 16 provides an example of a BranchData.txt file. 
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure16.png?direct&600 |}}| +| {{ :​start:​hype_tutorials:​hype_setup_tutorial:​branchdata.png?600&direct }}                                                                                                                                                                                                                                                                                                                                                                                                             ​
-|//Figure 16: BranchData.txt example. Sourceid is the SUBID with the bifurcation. Branchid is the SUBID of the receiving flow and this must be located in a row below the subbasin with bifurcation in Geodata.txt. Mainpart is the fraction of flow which flows in the main branch (not to branchid). Maxqmain/​Minqmain ​is maximum/​minimum flow in the main path and Maxqbranch ​is the maximum flow in the branch//|+| //Figure 16: BranchData.txt example. Sourceid is the SUBID with the bifurcation. Branchid is the SUBID of the receiving flow and this must be located in a row below the subbasin with bifurcation in GeoData.txt. Mainpart is the fraction of flow which flows in the main branch (not to branchid). Maxqmain is maximumflow ​in the main path. It is also possible to set limits for the branch ​path. The columns NAME and TYPE are just informative columns and can be excluded.//  |
  
  
Line 220: Line 241:
 Qobs.txt contains observations of discharge in m3/s for each time step. An example of Qobs.txt is given in Fig. 17. Qobs.txt contains observations of discharge in m3/s for each time step. An example of Qobs.txt is given in Fig. 17.
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure17.png?​direct&​300 |}}| +|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​qobs.png?​direct&​300 |}}| 
-|//Figure 17: Example of Qobs.txt . First column is used for the date of observation. Then each column have the SUBID the data is given for as header. Missing values should be given as -9999.//|+|//Figure 17: Example of Qobs.txt . First column is used for the date of observation ​and must be continuous. Then each column have the SUBID the data is given for as header. Missing values should be given as -9999 since 0 will be interpreted as no flow.//|
  
 Suggestions for quality assurance in discharge observations:​ Suggestions for quality assurance in discharge observations:​
  
-  * Compare the modelled upstream area of the SUBID and the gauging stations metadata. Correct and adjust routing or position of station if necessary. Decide how large discrepancies to accept. (This was probably already done if forced points have been used during the routing and delineation of subbasins ​in [[http://​hype.sourceforge.net/​WHIST/​|WHIST]]).+  * Compare the modelled upstream area of the SUBID and the gauging stations metadata. Correct and adjust routing or position of station if necessary. Decide how large discrepancies to accept. (This was probably already done if forced points have been used during the routing and delineation of subbasins.
   * Analyse the time series. Is the time period of interest represented?​ Are there lot of missing data? Is the gauging stations situated in an area with severe regulations? ​   * Analyse the time series. Is the time period of interest represented?​ Are there lot of missing data? Is the gauging stations situated in an area with severe regulations? ​
  
-==== Observation data other than discharge (xobs.txt) ====+==== Observation data other than discharge (Xobs.txt) ====
  
 The Xobs.txt file can contain observations of several selected variables, see more information in the [[start:​hype_file_reference:​xobs.txt|file reference entry for Xobs.txt]]. An example of an Xobs.txt file is shown in Fig. 18. The Xobs.txt file can contain observations of several selected variables, see more information in the [[start:​hype_file_reference:​xobs.txt|file reference entry for Xobs.txt]]. An example of an Xobs.txt file is shown in Fig. 18.
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure18.png?​direct&​300 |}}|+|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​xobs.png?​direct&​300 |}}|
 |//Figure 18: An example of an Xobs.txt file with observed evapotranspiration and potential evaporation in mm/​timestep.//​| |//Figure 18: An example of an Xobs.txt file with observed evapotranspiration and potential evaporation in mm/​timestep.//​|
  
Line 240: Line 261:
 A HYPE model run is started by placing the HYPE executable file in the model folder and run it. Please read the information in the [[start:​hype_tutorials:​short_intro#​quick_guide|Quick Guide]] for details. ​ A HYPE model run is started by placing the HYPE executable file in the model folder and run it. Please read the information in the [[start:​hype_tutorials:​short_intro#​quick_guide|Quick Guide]] for details. ​
  
-HYPE returns with a Code 84 message after a successful run. In Fig. 19 you can see an example of a HYPE model set up.+In Fig. 19 you can see an example of a HYPE model set up, just a collection of text-files and the executalbe HYPE code.
  
-|{{ :​start:​hype_tutorials:​hype_setup_tutorial:​figure19.png?direct&250 |}}| +| {{ :​start:​hype_tutorials:​hype_setup_tutorial:​hypefsetup.png?250&direct }}  
-|//Figure 19: Example of HYPE model set up.//|+| //Figure 19: Example of HYPE model set up.//                               ​|
  
  
start/hype_tutorials/hype_setup_tutorial.1435592080.txt.gz · Last modified: 2023/11/16 14:28 (external edit)