diff --git a/README.md b/README.md index e019e6c3..bc96531e 100644 --- a/README.md +++ b/README.md @@ -70,7 +70,7 @@ mkdir tests/data/LF_ETRS89_UseCase/out python src/lisf1.py tests/data/LF_ETRS89_UseCase/settings/cold.xml ``` -If the command above successed without errors, producing dis.nc into tests/data/LF_ETRS89_UseCase/out folder, your lisflood installation was correct. +If the command above succeeded without errors, producing dis.nc into tests/data/LF_ETRS89_UseCase/out folder, your lisflood installation was correct. ### Docker image @@ -154,7 +154,7 @@ These tests could take 30 minutes or several hours, depending on your machine. You can find full description and implementation details at [Test documentation](/docs/5_annex_tests/index.md) page. -**Note**: If yuor pull request is about a new feature you may want to integrate in LISFLOOD, +**Note**: If your pull request is about a new feature you may want to integrate in LISFLOOD, ensure to include tests with good coverage for it. For more info about pytest, see [official website](https://docs.pytest.org/en/latest/). diff --git a/docs/0_disclaimer/index.md b/docs/0_disclaimer/index.md index 92e7169c..41682502 100644 --- a/docs/0_disclaimer/index.md +++ b/docs/0_disclaimer/index.md @@ -2,4 +2,4 @@ Both the source code and the OS LISFLOOD documentation (including the [LISFLOOD Model Documentation](https://ec-jrc.github.io/lisflood-model/), the [LISFLOOD User Guide](https://ec-jrc.github.io/lisflood-code/) and the [LISVAP documentation](https://ec-jrc.github.io/lisflood-lisvap/)) have been carefully inspected before publishing. However, no warranties, either expressed or implied, are made concerning the accuracy, completeness, reliability, usability, performance, or fitness for any particular purpose of the information contained in this documentation, to the source code described in this documentation, and to other material supplied in connection therewith. The material is provided \"as is\". The entire risk as to its quality and performance is with the user. -Users are encouraged to submit questions and/or report errors concering the Documentation, User Guide, source code by opening a new issue in https://github.com/ec-jrc/lisflood-code/issues (LISFLOOD) or in https://github.com/ec-jrc/lisflood-lisvap/issues (LISVAP). +Users are encouraged to submit questions and/or report errors concerning the Documentation, User Guide, source code by opening a new issue in https://github.com/ec-jrc/lisflood-code/issues (LISFLOOD) or in https://github.com/ec-jrc/lisflood-lisvap/issues (LISVAP). diff --git a/docs/0_references/index.md b/docs/0_references/index.md index 8c5a0e40..37b50758 100644 --- a/docs/0_references/index.md +++ b/docs/0_references/index.md @@ -2,7 +2,7 @@ Allen, R. G., Pereira, L. S., Raes, D., and Smith, M.: FAO Irrigation and Drainage Paper No. 56: Crop Evapotranspiration (guidelines for computing crop water requirements), 1998. [available online: https://www.researchgate.net/publication/284300773_FAO_Irrigation_and_drainage_paper_No_56, last accessed: 13.05.2021.] -Anderson, 2006Anderson, E., 2006. *Snow Accumulation and Ablation Model -- SNOW-17*. Technical report. +Anderson, E., 2006. *Snow Accumulation and Ablation Model -- SNOW-17*. Technical report. Aston, A.R., 1979. Rainfall interception by eight small trees. Journal of Hydrology 42, 383-396. @@ -38,7 +38,7 @@ Goudriaan, J., 1977. Crop micrometeorology: a simulation study. Simulation Monog Hanazaki, R., Yamazaki, D., & Yoshimura, K. (2022). Development of a reservoir flood control scheme for global flood models. Journal of Advances in Modeling Earth Systems, 14, e2021MS002944. https://doi.org/10.1029/2021MS002944 -Hock, 2003Hock, R., 2003. Temperature index melt modelling in mountain areas. *Journal of Hydrology*, 282(1-4), 104--115. +Hock, R., 2003. Temperature index melt modelling in mountain areas. *Journal of Hydrology*, 282(1-4), 104--115. Laborte, A., Gutierrez, M., Balanza, J. et al. RiceAtlas, a spatial database of global rice calendars and production. Sci Data 4, 170074 (2017). https://doi.org/10.1038/sdata.2017.74 @@ -97,9 +97,9 @@ Van der Knijff, J. M., Younis, J. and de Roo, A. P. J.: LISFLOOD: A GIS-based di Van Genuchten, M.Th., 1980. A closed-form equation for predicting the hydraulic conductivity of unsaturated soils. Soil Science Society of America Journal 44, 892-898. -Viviroli et al., 2009Viviroli, D., Zappa, M., Gurtz, J., & Weingartner, R., 2009. An introduction to the hydrological modelling system PREVAH and its pre- and post-processing-tools. *Environmental Modelling & Software*, 24(10), 1209--1222. +Viviroli, D., Zappa, M., Gurtz, J., & Weingartner, R., 2009. An introduction to the hydrological modelling system PREVAH and its pre- and post-processing-tools. *Environmental Modelling & Software*, 24(10), 1209--1222. -Vogt et al., 2007Vogt, J., Soille, P., de Jager, A., Rimaviciute, E., Mehl, W., Foisneau, S., Bodis, K., Dusart, M., Parachini, M., Hasstrup, P.,2007. *A pan-European River and Catchment Database*. JRC Reference Report EUR 22920 EN, Institute for Environment and Sustainability, Joint Research Centre of the European Commission. +Vogt, J., Soille, P., de Jager, A., Rimaviciute, E., Mehl, W., Foisneau, S., Bodis, K., Dusart, M., Parachini, M., Hasstrup, P.,2007. *A pan-European River and Catchment Database*. JRC Reference Report EUR 22920 EN, Institute for Environment and Sustainability, Joint Research Centre of the European Commission. Von Hoyningen-Huene, J., 1981. Die Interzeption des Niederschlags in landwirtschaftlichen Pflanzenbeständen (Rainfall interception in agricultural plant stands). In: Arbeitsbericht Deutscher Verband für Wasserwirtschaft und Kulturbau, DVWK, Braunschweig, p.63. diff --git a/docs/1_introduction_LISFLOOD/index.md b/docs/1_introduction_LISFLOOD/index.md index d100b24f..a8d31c1f 100644 --- a/docs/1_introduction_LISFLOOD/index.md +++ b/docs/1_introduction_LISFLOOD/index.md @@ -6,15 +6,15 @@ Its most prominent application is probably within the [European Flood Awareness operated under [Copernicus Emergency Management System, CEMS](https://emergency.copernicus.eu/). Its wide applicability is due to its modular structure as well as its temporal and spatial flexibility. -The user to control the model inputs and outputs and the selection of the model modules. +The user can control the model inputs and outputs and the selection of the model modules. The model can be extended with additional modules when need arises, to satisfy the new target objective. At the same time the model has been designed to be applied across a wide range of spatial and temporal scales. -OS LISFLOOD is grid-based, and applications so far have employed grid cells of as little as 100 metres for medium-sized catchments, and up kilometer scale for continental and global applications. +OS LISFLOOD is grid-based, and applications so far have employed grid cells of as little as 100 metres for medium-sized catchments, and up to kilometer scale for continental and global applications. OS LISFLOOD can be used to generate long-term water balance simulations (climatology runs, with hourly to daily time steps), as well as individual flood events (with hourly to daily time steps). Although LISFLOOD's primary output product is channel discharge, all internal rate and state variables (soil moisture, for example) can be written as output as well. All output can be written as grids, or time series at user-defined points or areas. The user has complete control over how output is written, thus minimising any waste of disk space or CPU time. -LISFLOOD is implemented in Python high level language: the users are recommented to refer to the chapter [Installation of the LISFLOOD model](../2_installation/index.md) and to the readme of the [OS LISFLOOD GitHub repository](https://github.com/ec-jrc/lisflood-code#lisflood-os) to find detailed information on requirements and installation protocol. +LISFLOOD is implemented in Python high level language: the users are recommended to refer to the chapter [Installation of the LISFLOOD model](../2_installation/index.md) and to the readme of the [OS LISFLOOD GitHub repository](https://github.com/ec-jrc/lisflood-code#lisflood-os) to find detailed information on requirements and installation protocol. [🔝](#top) diff --git a/docs/1_introduction_usermanual/index.md b/docs/1_introduction_usermanual/index.md index 930a33d1..de80e429 100644 --- a/docs/1_introduction_usermanual/index.md +++ b/docs/1_introduction_usermanual/index.md @@ -8,12 +8,12 @@ In order to apply this knowledge into practice, we provide two fully implemented Note, this document is **not a LISFLOOD model documentation**. The [lisflood-model official documentation](https://ec-jrc.github.io/lisflood-model/) contains the most up-to-date and complete technical documentation of the LISFLOOD model. This includes all the concepts and model equations of all the standard LISFLOOD processes, but also all the optional modules. -OS LISFLOOD users might also be interested in the following complemetary open-source repositories: +OS LISFLOOD users might also be interested in the following complementary open-source repositories: -* [LISVAP](https://github.com/ec-jrc/lisflood-lisvap) allows the computation of reference evapotrasnpiration gridded dataset. The relevant documentation can be found at [LISVAP documentation](https://ec-jrc.github.io/lisflood-lisvap/) -* [OS LISFLOOD calibration tool](https://github.com/ec-jrc/lisflood-calibration) enables model parameter documentation. The relevant documentation is available at [Calibration Tool documentation](https://ec-jrc.github.io/lisflood-calibration/). +* [LISVAP](https://github.com/ec-jrc/lisflood-lisvap) allows the computation of reference evapotranspiration gridded dataset. The relevant documentation can be found at [LISVAP documentation](https://ec-jrc.github.io/lisflood-lisvap/) +* [OS LISFLOOD calibration tool](https://github.com/ec-jrc/lisflood-calibration) enables model parameter calibration. The relevant documentation is available at [Calibration Tool documentation](https://ec-jrc.github.io/lisflood-calibration/). * [OS LISFLOOD utilities](https://github.com/ec-jrc/lisflood-utilities) support the preparation of model inputs, the post-processing and comparison of model outputs. The relevant documentation is provided in the [lisflood-utilities repository](https://github.com/ec-jrc/lisflood-utilities#lisflood-utilities). -* [pyg2p](https://github.com/ec-jrc/pyg2p) allows re-gridding and interpolation of meteorological files in GRIB format to nectdf (and pcraster) format. The relevant documentation is provided in the [pyg2p repositrory](https://github.com/ec-jrc/pyg2p#pyg2p) +* [pyg2p](https://github.com/ec-jrc/pyg2p) allows re-gridding and interpolation of meteorological files in GRIB format to NetCDF (and pcraster) format. The relevant documentation is provided in the [pyg2p repository](https://github.com/ec-jrc/pyg2p#pyg2p) [🔝](#top) diff --git a/docs/2_installation/index.md b/docs/2_installation/index.md index be7eca13..6c788a0c 100644 --- a/docs/2_installation/index.md +++ b/docs/2_installation/index.md @@ -56,7 +56,7 @@ Using conda environment is very handy since installing latest PCRaster and its d 1. Install [miniconda](https://docs.conda.io/en/latest/miniconda.html) 2. Create a conda env named "lisflood" and install dependencies: ``` -conda create --name lisflood python=3.8 -c conda-forge +conda create --name lisflood python=3.10 -c conda-forge conda activate lisflood conda install -c conda-forge pcraster pip install lisflood-model diff --git a/docs/3_step1_ESSENTIAL_concepts_to_get_started/index.md b/docs/3_step1_ESSENTIAL_concepts_to_get_started/index.md index 8fc6733d..6e1c74f8 100644 --- a/docs/3_step1_ESSENTIAL_concepts_to_get_started/index.md +++ b/docs/3_step1_ESSENTIAL_concepts_to_get_started/index.md @@ -11,13 +11,13 @@ In order the run a simulation you will need: - Meteo input maps - Static input maps - - Tables, only in case specific features such as reservoirs and lakes are included in the modeling excercis + - Tables, only in case specific features such as reservoirs and lakes are included in the modeling exercise - An empty output directory where all model data can be written - OS LISFLOOD settings file in .xml format The section [Input files](../3_step3_preparing-input-files/index.md) provides a detailed description of input maps and tables. -The settings file (settings.xml) allows the selection of input maps, modelling options, and output variables and storage folder. The settings .xml is the essential argument of OS LISFLOOD command line. The section below presents its main components, an in depth descrition is provided in the section [Step 2: Preparing the Settings file](../3_step2_preparing-setting-file/index.md). +The settings file (settings.xml) allows the selection of input maps, modelling options, and output variables and storage folder. The settings .xml is the essential argument of OS LISFLOOD command line. The section below presents its main components, an in depth description is provided in the section [Step 2: Preparing the Settings file](../3_step2_preparing-setting-file/index.md). ## OS LISFLOOD settings file (settings.xml) @@ -65,9 +65,9 @@ The sections ‘lfuser’, ‘lfoptions’ and ‘lfbinding’' have different p For example: ```xml - 'lfuser' secttion: + 'lfuser' section: - 'lfbinding' secttion: + 'lfbinding' section: ``` diff --git a/docs/3_step2_preparing-setting-file/index.md b/docs/3_step2_preparing-setting-file/index.md index 6c528f80..d090e20c 100644 --- a/docs/3_step2_preparing-setting-file/index.md +++ b/docs/3_step2_preparing-setting-file/index.md @@ -1,12 +1,12 @@ # Step 2: Preparing the Settings file -This page describes how to prepare your own settings file. Instead of writing the settings file completely from scratch, we suggest usinng the [reference settings file](https://github.com/ec-jrc/lisflood-code/tree/master/src/lisfloodSettings_reference.xml) as a starting point. +This page describes how to prepare your own settings file. Instead of writing the settings file completely from scratch, we suggest using the [reference settings file](https://github.com/ec-jrc/lisflood-code/tree/master/src/lisfloodSettings_reference.xml) as a starting point. In order the run a simulation you will need: - Meteo input maps - Static input maps - - Tables (when reservoirs and lakes are included in the modeling excercise) + - Tables (when reservoirs and lakes are included in the modeling exercise) - An (empty) directory where all model data can be written exists If this is all true, the settings file can be prepared very quickly by editing the items in the 'lfuser' element. The following is a detailed description of the different sections of the 'lfuser' element. The present LISFLOOD version contains process-related parameters (not taking into account the parameters that are defined through the maps). These are all defined in the 'lfuser' element, and default values are given for each of them. Even though *any* of these parameters can be treated as calibration constants, doing so for *all* of them would lead to serious over-parameterisation problems. In the description of these parameters we will therefore provide some suggestions as to which parameters should be used for calibration, and which ones are better left untouched. @@ -21,7 +21,7 @@ When using the [reference settings .xml](https://github.com/ec-jrc/lisflood-cod >Please note that the template contains all the settings for a warm start run; the paths to the initial maps must be replaced with the initial bogus values in order to perform a pre-run or a cold start run. -TIP: *$(ProjectDir)* or *$(ProjectPath)* cab used as built-in variable in the XML settings, to refer the project folder. +TIP: *$(ProjectDir)* or *$(ProjectPath)* can used as built-in variable in the XML settings, to refer the project folder. ### Time-related constants @@ -67,7 +67,7 @@ The 'lfuser' section starts with a number of constants that are related to the s ``` -- As a good practice, **CalendarDayStart** shoudl be set equal to the calendar day of the first timestep of input mapstacks. +- As a good practice, **CalendarDayStart** should be set equal to the calendar day of the first timestep of input mapstacks. Format can be a date in several formats, as long as day number is in first position. eg:
*Value="02/01/1990" = $2^{nd}$ January 1990* @@ -362,7 +362,7 @@ These parameters are all related to the [routing of water in the channels](https Minimum channel gradient (for kin. wave: slope cannot be 0) - Coould be set to 0.00001 when using kinematic and diffusive wave modelling + Could be set to 0.00001 when using kinematic and diffusive wave modelling ``` @@ -381,7 +381,7 @@ These parameters are all related to the [routing of water in the channels](https ### Diffusive wave routing parameters -The following parameters are related to the [diffusive wave routing](https://ec-jrc.github.io/lisflood-model/3_14_optLISFLOOD_diffusive-wave/) in river channels. The multiplier *CalChanMan3* can be used to fine-tune the diffusive wave propagation when using the Muskingum-Cunge-Todini (MCT) routing, and it can be defined as either a single value or a map. The map *ChannelsMCT* is a Bolean map with the mask of rivers where MCT wave routing must be used. The parameter *ChanGradMaxMCT* defines the maximum riverbed slope for river grid cells using the MCT wave routing. The parameter is provided as a single number and it is recommended to set it to values < 0.001 and > *ChanGradMin* +The following parameters are related to the [diffusive wave routing](https://ec-jrc.github.io/lisflood-model/3_14_optLISFLOOD_diffusive-wave/) in river channels. The multiplier *CalChanMan3* can be used to fine-tune the diffusive wave propagation when using the Muskingum-Cunge-Todini (MCT) routing, and it can be defined as either a single value or a map. The map *ChannelsMCT* is a Boolean map with the mask of rivers where MCT wave routing must be used. The parameter *ChanGradMaxMCT* defines the maximum riverbed slope for river grid cells using the MCT wave routing. The parameter is provided as a single number and it is recommended to set it to values < 0.001 and > *ChanGradMin* ```xml ************************************************************** @@ -409,7 +409,7 @@ The following parameters are related to the [diffusive wave routing](https://ec- ``` - **CalChanMan3** is a multiplier that is applied to the Manning’s roughness map of the [channel system](https://ec-jrc.github.io/lisflood-model/2_16_stdLISFLOOD_channel-routing/) [-] for the grid cells where MCT routing is used -- **ChannelsMCT** is Bolean mask including the rivers grid cells using the MCT wave routing [-] +- **ChannelsMCT** is oBolean mask including the rivers grid cells using the MCT wave routing [-] - **ChanGradMaxMCT** is a upper limit for the channel gradient used in the calculation of the MCT wave routing [m/m] @@ -504,7 +504,7 @@ Here you can define the prefix that is used for each meteorological variable, LA - **PrefixET0** is the prefix of the potential (reference) evapotranspiration maps -- **PrefixLAI**, **PrefixLAIForest** ,**PrefixLAIIrrigated** are the prefix of the Leaf Area Index maps for the three land cover fractions +- **PrefixLAI**, **PrefixLAIForest** ,**PrefixLAIIrrigation** are the prefix of the Leaf Area Index maps for the three land cover fractions - **PrefixWaterUseDomestic** is the prefix of the domestic [water use maps](https://ec-jrc.github.io/lisflood-model/2_18_stdLISFLOOD_water-use/) (optional). Domestic use was indicated here as an example. @@ -512,13 +512,13 @@ Here you can define the prefix that is used for each meteorological variable, LA ### Initial conditions: OS LISFLOOD prerun, cold start, warm start -OS LISFLOOD prerun simulation has the purpose to adequately initialize the state of the slow storages, namely grounwater zone and soil. OS LISFLOOD prerun can also be referred to as initialization run. This simulation must always be performed. OS LISFLOOD prerun output must be used to initialize the OS LISFLOOD cold start run. +OS LISFLOOD prerun simulation has the purpose to adequately initialize the state of the slow storages, namely groundwater zone and soil. OS LISFLOOD prerun can also be referred to as initialization run. This simulation must always be performed. OS LISFLOOD prerun output must be used to initialize the OS LISFLOOD cold start run. -OS LISFLOOD cold start run and warm start run deliver the actual model outputs to be usef for analysis/forecasts. +OS LISFLOOD cold start run and warm start run deliver the actual model outputs to be used for analysis/forecasts. -OS LISFLOOD cold start run takes as input the OS LISFLOOD prerun output for the slow storages, while fast(er) respoding storages (e.g. channel volume) are set to bogus values. It is always recommended to discard the initial (3) years of the OS LISFLOOD cold start to allow adequate initialization of fast(er) respoding storages. +OS LISFLOOD cold start run takes as input the OS LISFLOOD prerun output for the slow storages, while fast(er) responding storages (e.g. channel volume) are set to bogus values. It is always recommended to discard the initial (3) years of the OS LISFLOOD cold start to allow adequate initialization of fast(er) responding storages. -OS LISFLOOD warm start resumes the computations from the end states of a preceeding simulation (cold start or warm start). +OS LISFLOOD warm start resumes the computations from the end states of a preceding simulation (cold start or warm start). A dedicated chapter about [model initialization](../3_step4_model-initialisation/index.md) provides more in-depth explanations of model prerun (initialization), cold start, and warm start. @@ -529,16 +529,17 @@ This page has the purpose to provide an overview of the variables requiring an i ************************************************************** INITIAL CONDITIONS (maps or single values) - ************************************************************** - + ************************************************************** initial overland flow water volume, direct runoff fraction [m3] - + + initial overland flow water volume, other + irrigated fraction [m3] - + + initial overland flow water volume, forest fraction [m3] @@ -649,11 +650,11 @@ This page has the purpose to provide an overview of the variables requiring an i - **OFDirect/Other/ForestInitValue** is the initial amount of water on the soil surface $[m^3]$ -- **SnowCoverInitAValue** is the initial snow cover on the soil surface in elevation zone **A** $[mm]$ +- **SnowCoverAInitValue** is the initial snow cover on the soil surface in elevation zone **A** $[mm]$ -- **SnowCoverInitBValue** is the initial snow cover on the soil surface in elevation zone **B** $[mm]$ +- **SnowCoverBInitValue** is the initial snow cover on the soil surface in elevation zone **B** $[mm]$ -- **SnowCoverInitCValue** is the initial snow cover on the soil surface in elevation zone **C** $[mm]$ +- **SnowCoverCInitValue** is the initial snow cover on the soil surface in elevation zone **C** $[mm]$ - **FrostIndexInitValue** ([**F**](https://ec-jrc.github.io/lisflood-model/2_05_stdLISFLOOD_frost-index/)) initial value of the frost index $[\frac{°C}{day}]$ @@ -669,17 +670,17 @@ This page has the purpose to provide an overview of the variables requiring an i - **TotalCrossSectionAreaInitValue** is the initial cross-sectional area $[m^2]$ of the water in the river channels (a substitute for initial discharge, which is directly dependent on this). A value of **-9999 ** sets the initial amount of water in the channel to half bankfull. -- **ThetaInit1Value** is the initial moisture content $[\frac{mm^3} {mm^3}]$ of the superficial soil layer (1a). A value of -**9999** will set the initial soil moisture content to field capacity. +- **ThetaInit1Value** is the initial moisture content $[\frac{mm^3} {mm^3}]$ of the superficial soil layer (1). A value of -**9999** will set the initial soil moisture content to field capacity. -- **ThetaInit2Value** is the initial moisture content $[\frac{mm^3} {mm^3}]$ of the upper soil layer (1b). A value of -**9999** will set the initial soil moisture content to field capacity. +- **ThetaInit2Value** is the initial moisture content $[\frac{mm^3} {mm^3}]$ of the upper soil layer (2). A value of -**9999** will set the initial soil moisture content to field capacity. -- **ThetaInit3Value** is the initial moisture content $[\frac{mm^3} {mm^3}]$ of the lower soil layer (2). A value of -**9999** will set the initial soil moisture content to field capacity. +- **ThetaInit3Value** is the initial moisture content $[\frac{mm^3} {mm^3}]$ of the lower soil layer (3). A value of -**9999** will set the initial soil moisture content to field capacity. -- **PrevDischarge** and **PrevDischargeAvg** are the initial discharge from previous run (instantaneous and average values in the last sub-roting step) $[\frac{m^3} {s}]$ used for lakes, reservoirs and transmission loss (only needed if option is on for lakes or reservoirs or transmission loss). A value of **-9999** sets the initial amount of discharge to equivalent of half bankfull. +- **PrevDischarge** and **PrevDischargeAvg** are the initial discharge from previous run (instantaneous and average values in the last sub-routing step) $[\frac{m^3} {s}]$ used for lakes, reservoirs and transmission loss (only needed if option is on for lakes or reservoirs or transmission loss). A value of **-9999** sets the initial amount of discharge to equivalent of half bankfull. - **PrevCmMCTInitValue** is the Courant number at the end of the previous step and it is only used for MCT wave routing [-]. A value of -**9999 ** sets the initial value to 1. -- **PrevDmMCTInitValue** is the Reynols number at the end of the previous step and it is only used for MCT wave routing [-]. A value of -**9999 ** sets the initial value to 0. +- **PrevDmMCTInitValue** is the Reynolds number at the end of the previous step and it is only used for MCT wave routing [-]. A value of -**9999 ** sets the initial value to 0. ```xml @@ -735,7 +736,7 @@ Users can set different combinations of optional modules and outputs (or none at For instance, using the inflow hydrograph option requires an input map and time series, which have to be specified in the settings file. If you want to report discharge maps at each time step, you will first have to specify the writing path and desired file name. -The [refernce xml settings file](https://github.com/ec-jrc/lisflood-code/blob/master/src/lisfloodSettings_reference.xml) includes definitions for most of the optional output maps and time series. +The [reference xml settings file](https://github.com/ec-jrc/lisflood-code/blob/master/src/lisfloodSettings_reference.xml) includes definitions for most of the optional output maps and time series. The use of the *output* options is described in detail in [a dedicated section](../5_annex_output-files/index.md). Within the 'lfoptions' element of the settings file, each option is defined using a 'setoption' element, which has the attributes 'name' and 'choice' (i.e. the actual value). For example: diff --git a/docs/3_step3_preparing-input-files/index.md b/docs/3_step3_preparing-input-files/index.md index 532eceba..970bfbc7 100644 --- a/docs/3_step3_preparing-input-files/index.md +++ b/docs/3_step3_preparing-input-files/index.md @@ -4,7 +4,7 @@ In the current version of OS LISFLOOD, all the model inputs are provided as eith ### INPUT MAPS -> Albeit OS LISFLOOD can still read maps in pcraster format, users are strongly recommended to prepare their own input maps in NetCDF format: pcraster format will be discarded in future versions of OS LISFLOOD (timeline not yet defined). Users interested in converting their existing pcraster maps into NetCDF format can refer to the [OS LISFLOOD untility pcr2nc](https://github.com/ec-jrc/lisflood-utilities#pcr2nc). +> Albeit OS LISFLOOD can still read maps in pcraster format, users are strongly recommended to prepare their own input maps in NetCDF format: pcraster format will be discarded in future versions of OS LISFLOOD (timeline not yet defined). Users interested in converting their existing pcraster maps into NetCDF format can refer to the [OS LISFLOOD utility pcr2nc](https://github.com/ec-jrc/lisflood-utilities#pcr2nc). LISFLOOD requires that all maps must have *identical* location attributes (number of rows, columns, cellsize, upper x and y coordinates). @@ -14,7 +14,7 @@ The input maps can be classified according to two main categories:
### Meteorological forcings -The meteorological forcing variables are defined in *map stacks*. A *map stack* is simply a series of maps, where each map represents the value of a variable at an individual time step.
It is recommented to use the netcdf format.
LISFLOOD is capable of reading meteorological forcings split into multiple files (e.g. yearly chuncks). To use this functionality, it is enough to add the symbol '\*' after the file name (e.g. ET0_\*). +The meteorological forcing variables are defined in *map stacks*. A *map stack* is simply a series of maps, where each map represents the value of a variable at an individual time step.
It is recommended to use the netcdf format.
LISFLOOD is capable of reading meteorological forcings split into multiple files (e.g. yearly chunks). To use this functionality, it is enough to add the symbol '\*' after the file name (e.g. ET0_\*). Generally used prefixes for the meteorological forcings maps are:
+ tp : total precipitation; units: mm/day.
@@ -34,7 +34,7 @@ The section [Static Maps](../4_Static-Maps-introduction) provides detailed guide + [general maps](../4_Static-Maps_general-maps/): area mask; landuse mask; grid-cell length; grid-cell area. + [topography](../4_Static-Maps_topography/): local drain direction; gradient; standard deviation of elevation; upstream area. + [land use maps](../4_Static-Maps_land-use/): fraction of forest; fraction of irrigated crops; fraction of rice crops; fraction of inland water; fraction of sealed surfaces; fraction of other land uses. -+ [land use depending](../4_Static-Maps_land-use-depending/):crop coefficient; crop group number; Manning/s's surface roughness; soil depth. ++ [land use depending](../4_Static-Maps_land-use-depending/):crop coefficient; crop group number; Manning's surface roughness; soil depth. + [soil hydraulic properties](../4_Static-Maps_soil-hydraulic-properties/): saturated hydraulic conductivity; soil water content at saturation; residual soil water content; parameters alpha and lambda of Van Genuchten's equations. + [channel geometry](../4_Static-Maps_channel-geometry/): channels mask; channels side slope; channels length; channels gradient; Manning's rougheness coefficient of the channels; channels bottom width; floodplain width; bankfull channels depth; MCT diffusive wave routing channels. + [leaf area index](../4_Static-Maps_leaf-area-index/): evolution of vegetation over time (leaf area index) for land covers forest, irrigated areas, others. @@ -44,7 +44,7 @@ The section [Static Maps](../4_Static-Maps-introduction) provides detailed guide + [sectoral water demand maps]: domestic, energetic, livestock, industrial water use. These maps represent the time series of spatially distributed values of water demand for domestic, energetic, livestock, and industrial water use. These maps are required only when activating the [water use module](https://ec-jrc.github.io/lisflood-model/2_18_stdLISFLOOD_water-use/) + outlet points: locations and IDs of the points for which OS LISFLOOD provides the time series of discharge values. -#### Role of "mask", "channels" ans "channelsMCT" maps +#### Role of "mask", "channels" and "channelsMCT" maps The mask map (i.e. domain.nc, also called area.nc) defines the model domain. In order to avoid unexpected results, **it is vital that all maps that are related to topography, land use and soil are defined** (i.e. don't contain a missing value) for each pixel that is "true" (has a Boolean 1 value) on the mask map. The same applies for all meteorological input and the Leaf Area Index maps. Similarly, all pixels that are "true" on the channels map must have some valid (non-missing) value on each of the channel parameter maps. At the same time, all pixels that have value "true" in the MCT rivers mask must also belong to the "channels" map. Undefined pixels can lead to unexpected behaviour of the model, output that is full of missing values, loss of mass balance and possibly even model crashes. Some maps needs to have values in a defined range e.g. the gradient map has to be greater than 0. When preparing their own input maps, users are recommended to refer to [these guidelines](../4_Static-Maps-introduction/). @@ -59,7 +59,7 @@ LISFLOOD needs to know the size properties of each grid cell (length, area) in o | PixelLengthUser | pixleng.map/nc | Map with pixel length

Unit: $[m]$,
*Range *of values: map \> 0* | | PixelAreaUser | pixarea.map/nc | Map with pixel area

*Unit:* $[m^2]$,
*Range of values: map \> 0* | -The values on both maps may vary in space. A limitation is that a pixel is always represented as a square, so length and width are considered equal (no rectangles). In order to tell LISFLOOD to use the maps a, you need to activate the special option "*gridSboveizeUserDefined*", which involves adding the following line to the LISFLOOD settings file: +The values on both maps may vary in space. A limitation is that a pixel is always represented as a square, so length and width are considered equal (no rectangles). In order to tell LISFLOOD to use the maps a, you need to activate the special option "*gridSizeUserDefined*", which involves adding the following line to the LISFLOOD settings file: ```xml @@ -75,9 +75,9 @@ Because Leaf area index maps follow a yearly circle, only a map stack of one yea #### Important technical note for the generation of the water regions map -Water demand and water abstraction are spatially distributed within each water region. As detailed [here](../2_18_stdLISFLOOD_water-use/), the water resources (surface water bodies and groundwater) are shared inside the water region in order to meet the cumulative requirements of the water region area. For this reason, it is strongly recommended to include the entire water region(s) in the modelled area. If a portion of the water region is not included in the modelled area, then LISFLOOD cannot adequately compute the water demand and abstraction. In other words, LISFLOOD will not be able to account for sources of water outside of the computational domain (it is important to notice that LISFLOOD will not crush but the results will be affected by this discrepancy). +Water demand and water abstraction are spatially distributed within each water region. As detailed [here](../2_18_stdLISFLOOD_water-use/), the water resources (surface water bodies and groundwater) are shared inside the water region in order to meet the cumulative requirements of the water region area. For this reason, it is strongly recommended to include the entire water region(s) in the modelled area. If a portion of the water region is not included in the modelled area, then LISFLOOD cannot adequately compute the water demand and abstraction. In other words, LISFLOOD will not be able to account for sources of water outside of the computational domain (it is important to notice that LISFLOOD will not crash but the results will be affected by this discrepancy). The inclusion of the complete water region in the computational domain becomes compulsory under the specific circumstances of model calibration. -Calibrated parameters are optimised for a specific model set up. It is often required to calibrate the parameters of several subcatchments inside a basin. Each calibration subcatchment must include a finite number of water regions (each water region can belong to only one subctatchment). If this condition is met, the calibrated parameters can be correctly optimised. Conversely, when a water region belongs to one or more calibration sub-catchments, the water resources are allocated and abstracted in different quantities when modelling the calibration subcatchment only or the entire basin. Similarly, the option groundwater smooth leads to different geometries of the cone of depression due to groundwater abstraction when modelling the subcatchment only or the entire basin. These two scenarios impede the correct calibration of the model parameters and must be avoided. The user is advised to switch off the groundwater smooth option and to ensure the consistency between water regions and calibration cacthments. The utility [waterregions](https://github.com/ec-jrc/lisflood-utilities/) can be used to 1) verify the consistency between calibration catchments and water regions or 2) create a water region map which is consistent with a set of calibration points. +Calibrated parameters are optimised for a specific model set up. It is often required to calibrate the parameters of several subcatchments inside a basin. Each calibration subcatchment must include a finite number of water regions (each water region can belong to only one subcatchment). If this condition is met, the calibrated parameters can be correctly optimised. Conversely, when a water region belongs to one or more calibration sub-catchments, the water resources are allocated and abstracted in different quantities when modelling the calibration subcatchment only or the entire basin. Similarly, the option groundwater smooth leads to different geometries of the cone of depression due to groundwater abstraction when modelling the subcatchment only or the entire basin. These two scenarios impede the correct calibration of the model parameters and must be avoided. The user is advised to switch off the groundwater smooth option and to ensure the consistency between water regions and calibration catchments. The utility [waterregions](https://github.com/ec-jrc/lisflood-utilities/) can be used to 1) verify the consistency between calibration catchments and water regions or 2) create a water region map which is consistent with a set of calibration points. ### INPUT TABLES @@ -87,7 +87,7 @@ LISFLOOD requires additional information for the adequate modelling of [lakes](h ### Organisation of input data -It is up to the user how the input data are organised. As an example, users might decide to organize base maps, meteorological maps, static maps, and tables in separate directories. It is strogly recommended to store output files in a separate directory. +It is up to the user how the input data are organised. As an example, users might decide to organize base maps, meteorological maps, static maps, and tables in separate directories. It is strongly recommended to store output files in a separate directory. For example: @@ -107,7 +107,7 @@ For example: - all **output** goes to one directory (e.g. 'out') -Users might consider the example of sub-folders organization provided in the public datasets: [OS LISLOOD static and parameter maps for GloFAS dataset](https://data.jrc.ec.europa.eu/dataset/68050d73-9c06-499c-a441-dc5053cb0c86) and [OS LISLOOD static and parameter maps for Europe](https://data.jrc.ec.europa.eu/dataset/f572c443-7466-4adf-87aa-c0847a169f23). +Users might consider the example of sub-folders organization provided in the public datasets: [OS LISFLOOD static and parameter maps for GloFAS dataset](https://data.jrc.ec.europa.eu/dataset/68050d73-9c06-499c-a441-dc5053cb0c86) and [OS LISFLOOD static and parameter maps for Europe](https://data.jrc.ec.europa.eu/dataset/f572c443-7466-4adf-87aa-c0847a169f23). diff --git a/docs/3_step4_model-initialisation/index.md b/docs/3_step4_model-initialisation/index.md index 450cf794..fda4b65f 100644 --- a/docs/3_step4_model-initialisation/index.md +++ b/docs/3_step4_model-initialisation/index.md @@ -1,16 +1,16 @@ -# Step 4: LISFLOOD initializion or prerun +# Step 4: LISFLOOD initialization or prerun Just as any other hydrological model, LISFLOOD needs to know the initial state (i.e. amount of water stored in the groundwater zone, soil, channels) of its internal state variables in order to start a simulation. However, in practice we hardly ever know the initial state of all state variables at a given time. Hence, the state of the initial storages must be estimated: this phase is the initialisation of a hydrological model. A OS LISFLOOD simulation requires at least a prerun and a cold start. In some cases, performing warm start simulations might be convenient. The types of OS LISFLOOD runs are explained below. This page focuses on the OS LISFLOOD prerun, the next page is dedicated to the cold start and the warm start. ->**OS LISFLOOD prerun** simulation has the purpose to adequately initialize the state of the slow storages, namely grounwater zone and soil. OS LISFLOOD prerun constitutes the **initialization run**. OS LISFLOOD prerun output is used as input to the OS LISFLOOD cold start run. +>**OS LISFLOOD prerun** simulation has the purpose to adequately initialize the state of the slow storages, namely groundwater zone and soil. OS LISFLOOD prerun constitutes the **initialization run**. OS LISFLOOD prerun output is used as input to the OS LISFLOOD cold start run. ->OS LISFLOOD cold start run and warm start run deliver the actual model outputs to be usef for analysis/forecasts. +>OS LISFLOOD cold start run and warm start run deliver the actual model outputs to be used for analysis/forecasts. ->**OS LISFLOOD cold start** run takes as input the OS LISFLOOD prerun output to initialize the slow storages (soil and groundwater). Initial values of fast(er) respoding storages (e.g. channel volume) are set to bogus values. It is always recommended to discard the initial (3) years of the OS LISFLOOD cold start to allow adequate initialization of fast(er) respoding storages. +>**OS LISFLOOD cold start** run takes as input the OS LISFLOOD prerun output to initialize the slow storages (soil and groundwater). Initial values of fast(er) responding storages (e.g. channel volume) are set to bogus values. It is always recommended to discard the initial (3) years of the OS LISFLOOD cold start to allow adequate initialization of fast(er) responding storages. ->**OS LISFLOOD warm start** resumes the computations from the end states of a preceeding simulation. +>**OS LISFLOOD warm start** resumes the computations from the end states of a preceding simulation. In this page we will: @@ -38,7 +38,7 @@ The initial amount of moisture in the upper soil layer only has a marked effect This behaviour provides a convenient and simple way to initialise the soil moisture state of the upper soil layer. Suppose we want to do a simulation of the year 1995. We obviously don't know the state of the soil at the beginning of that year. However, we can get around this by starting the simulation a bit earlier than 1995, say one year. In that case we use the year 1994 as a *spin-up* period, assuming that by the start of 1995 the influence of the initial conditions (i.e. 1-1-1994) is negligible. -Even though the use of a sufficiently long spin-up period usually results in a correct initialisation of many state variables, the time needed to initialise any storage component of the model is dependent on its specific water average residence time. As briefly shown above, the moisture content of the upper soil layer tends to respond relatively quickly to meteorological forcing variables (precipitation, evapo(transpi)ration). As a result, relatively short spin-up periods are sufficient to initialise this storage component. At the other extreme, the response of the (thick) lower soil layers and of the lower groundwater zone is generally very slow. +Even though the use of a sufficiently long spin-up period usually results in a correct initialisation of many state variables, the time needed to initialise any storage component of the model is dependent on its specific average residence time of the water. As briefly shown above, the moisture content of the upper soil layer tends to respond relatively quickly to meteorological forcing variables (precipitation, evapo(transpi)ration). As a result, relatively short spin-up periods are sufficient to initialise this storage component. At the other extreme, the response of the (thick) lower soil layers and of the lower groundwater zone is generally very slow. To explain the challenge of the adequate initialization of the lower groundwater zone, we resume here the content presented in [this chapter](https://ec-jrc.github.io/lisflood-model/2_13_stdLISFLOOD_groundwater/) of OS LISFLOOD Model Documentation. @@ -46,7 +46,7 @@ The Figure below shows the results of two numerical experiments. In the upper Fi -**Figure** Two 10-year simulations of lower zone storage with constant inflow. Upper Figure: high initial storage, storage approaches steady-state storage +**Figure:** Two 10-year simulations of lower zone storage with constant inflow. Upper Figure: high initial storage, storage approaches steady-state storage (dashed) after about 1500 days. Lower Figure: low initial storage, storage doesn’t reach steady-state within 10 years. At this point it should be clear that being able to know the ‘end’ storages in the Figure above in advance would be very helpful, because it would eliminate any trend in the water content of the lower groundwater zone. @@ -70,7 +70,7 @@ The complete list of initial state values for a **OS LISFLOOD prerun** is presen ### Initialization of volumetric soil moisture content -> An improved initialization scheme has been implemented in OS-LISFLOOD v5, allowing to remove non-realistic trends in the thrid soil layer volumetric soil moisture content and consequent fictitious discharge values in the channels. There were previously observed, for example, in arid climates. Albeit the former initialization strategy with bogus values is still feasibile, the use of the methodology explained here is highly recommended, for all modelling excercises. +> An improved initialization scheme has been implemented in OS-LISFLOOD v5, allowing to remove non-realistic trends in the third soil layer volumetric soil moisture content and consequent fictitious discharge values in the channels. These were previously observed, for example, in arid climates. Albeit the former initialization strategy with bogus values is still feasible, the use of the methodology explained here is highly recommended, for all modelling exercises. OS LISFLOOD prerun provides in output end states and average fluxes. The end states are the volumetric soil moisture content for the three soil layers and the three land covers (9 maps). The average fluxes represent the average infiltration (over the simulation period) from the soil layer 2 to soil layer 3, for the three land cover fractions (3 maps indicated as *SeepTopToSubBAverageOther/Forest/Irrigated*). In the cold run, the end states are used to initialise the volumetric soil moisture content of soil layers 1 and 2. The initialisation of the volumetric soil moisture content of soil layer 3 makes use of the relevant end state and of the fluxes. Specifically, according to the steady-state approach, the model tries to enable long term equilibrium conditions between average inflow and outflow fluxes in the third soil layer. @@ -80,7 +80,7 @@ $$ q_{soil2to3,fraction} = SeepTopToSubBAverageFraction $$ -The prerun must include a sufficiently long simulation period (a few decades) to allow the computation of representative valuse of *SeepTopToSubBAverageOther/Forest/Irrigated*. Furthermore, accounting for an adequate spin-up period of the prerun allows is recommended to compute realistic average fluxes values. This latter outcome can be achieved by adequately setting the value of *NumDaysSpinUp* (recommended value: 1095 days, i.e. 3 years). +The prerun must include a sufficiently long simulation period (a few decades) to allow the computation of representative values of *SeepTopToSubBAverageOther/Forest/Irrigated*. Furthermore, accounting for an adequate spin-up period of the prerun is recommended to compute realistic average fluxes values. This latter outcome can be achieved by adequately setting the value of *NumDaysSpinUp* (recommended value: 1095 days, i.e. 3 years). Within OS LISFLOOD, the outflow from the third soil layer to the upper groundwater zone is defined by the equations explained in the chapter [Soil moisture redistribution](https://ec-jrc.github.io/lisflood-model/2_12_stdLISFLOOD_soilmoisture-redistribution/) of the [Model Documentation](https://ec-jrc.github.io/lisflood-model/). @@ -101,12 +101,12 @@ Prerun end states of volumetric soil moisture of layer 3 are used as initial gue ### Initialization of the upper groundwater zone water content -To initialize the upper groudwater zone water content it is recommended to use the end state generated by the prerun.
+To initialize the upper groundwater zone water content it is recommended to use the end state generated by the prerun.
### Initialisation of the lower groundwater zone water content -According to the steady-state approach, the condition in which *the lower groundwater zone storage is constant over time means that the in- and outflow terms balance each other out*. OS LISFLOOD approach for the computation of inflow, outflow, and storage variation is explained in the chapter [Groudwater](https://ec-jrc.github.io/lisflood-model/2_13_stdLISFLOOD_groundwater/) of the [Model Documentation](https://ec-jrc.github.io/lisflood-model/). +According to the steady-state approach, the condition in which *the lower groundwater zone storage is constant over time means that the in- and outflow terms balance each other out*. OS LISFLOOD approach for the computation of inflow, outflow, and storage variation is explained in the chapter [Groundwater](https://ec-jrc.github.io/lisflood-model/2_13_stdLISFLOOD_groundwater/) of the [Model Documentation](https://ec-jrc.github.io/lisflood-model/). The prerun computes the average net inflow $LZavin$ over the simulation period. For this purpose, the prerun must include a sufficiently long simulation period (a few decades) to achieve representative $LZavin$ values. @@ -166,7 +166,7 @@ $$ Number of days to be discarded when computing the average fluxes in the initialization (prerun) simulation. The use of NumDaysSpinUp avoids spurious large fluxes values driven by bogus initial conditions. - Recommended value when performing the initialiaztion (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) + Recommended value when performing the initialization (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) Value for lisflood cold run, warm start prerun/run: 0 @@ -217,7 +217,7 @@ Similarly, set the name of the reporting map for the end states in sect ```xml - ``` 3) Activate reporting maps (in NetCDF format) in section of Settings.XML file using: @@ -267,13 +267,14 @@ Similarly, set the name of the reporting map for the end states in sect - - ## Setting-up of a LISFLOOD prerun in temporal chunks Due to specific settings of the computational infrastructure (e.g. timewall that limits the maximum duration of a job), it might be necessary to complete the LISFLOOD initialization in chunks. -As an example, the full initialization period 02/01/1980-01/01/2025 must be computed in three temporal chunks (a) 02/01/1980 00:00 - 01/01/1995 00:00, (b) 02/01/1995 00:00 - 01/01/2010 00:00, (c) 02/01/2010 00:00 - 01/01/2025 00:00 +As an example, the full initialization period 02/01/1980-01/01/2025 must be computed in three temporal chunks: +* (a) 02/01/1980 00:00 - 01/01/1995 00:00, +* (b) 02/01/1995 00:00 - 01/01/2010 00:00, +* (c) 02/01/2010 00:00 - 01/01/2025 00:00 Starting with LISFLOOD v5, the computation of the initialization run in temporal chunk can be performed by following the instructions below (the same instructions apply with SplitRouting on or off) @@ -291,7 +292,7 @@ Starting with LISFLOOD v5, the computation of the initialization run in temporal Number of days to be discarded when computing the average fluxes in the initialization (prerun) simulation. The use of NumDaysSpinUp avoids spurious large fluxes values driven by bogus initial conditions. - Recommended value when performing the initialiaztion (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) + Recommended value when performing the initializtion (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) Value for lisflood cold run, warm start prerun/run: 0 @@ -379,7 +380,7 @@ Prerun (a) generates the following intermediate outputs: Number of days to be discarded when computing the average fluxes in the initialization (prerun) simulation. The use of NumDaysSpinUp avoids spurious large fluxes values driven by bogus initial conditions. - Recommended value when performing the initialiaztion (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) + Recommended value when performing the initialization (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) Value for lisflood cold run, warm start prerun/run: 0 @@ -467,7 +468,7 @@ Prerun (b) uses the intermediate outputs of prerun(a) and generates an update of Number of days to be discarded when computing the average fluxes in the initialization (prerun) simulation. The use of NumDaysSpinUp avoids spurious large fluxes values driven by bogus initial conditions. - Recommended value when performing the initialiaztion (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) + Recommended value when performing the initialization (prerun) in one chunk or the cold start of the initialization (prerun) >= 1095 (3 years) Value for lisflood cold run, warm start prerun/run: 0 @@ -478,36 +479,22 @@ Prerun(c) uses the intermediate outputs of prerun(b) and returns the outputs for Therefore, Prerun(c) generates all the files to be used for the LISFLOOD Cold Start. These outputs are: - * lzavin.nc - - * avgdis.nc - - * uz.end.nc, groundwater upper zone water content - other land cover fraction - - * uzf.end.nc, groundwater upper zone water content - forest land cover fraction - - * uzi.end.nc, groundwater upper zone water content - irrigation land cover fraction - - * th1.end.nc, soil moisture - other land cover fraction - first layer - - * th2.end.nc, soil moisture - other land cover fraction - second layer - - * th3.end.nc, soil moisture - other land cover fraction - third layer - - * thf1.end.nc, soil moisture - forest land cover fraction - first layer - - * thf2.end.nc, soil moisture - forest land cover fraction - second layer - - * thf3.end.nc, soil moisture - forest land cover fraction - third layer - - * thi1.end.nc, soil moisture - irrigation land cover fraction - first layer - - * thi2.end.nc, soil moisture - irrigation land cover fraction - second layer - - * thi3.end.nc, soil moisture - irrigation land cover fraction - third layer - - * SeepTopToSubBAverageOtherMap.nc, average flux from second to third soil layer - other land cover fraction - - * SeepTopToSubBAverageForestMap.nc, average flux from second to third soil layer - forest land cover fraction - - * SeepTopToSubBAverageIrrigationMap.nc, average flux from second to third soil layer - irrigation land cover fraction + | Output file | Description | +|-------------|-------------| +| lzavin.nc | Average percolation rate from upper to lower groundwater zone | +| SeepTopToSubBAverageOtherMap.nc | Average flux from layer 2 to layer 3 — other fraction | +| SeepTopToSubBAverageForestMap.nc | Average flux from layer 2 to layer 3 — forest fraction | +| SeepTopToSubBAverageIrrigationMap.nc | Average flux from layer 2 to layer 3 — irrigation fraction | +| avgdis.nc | Average discharge (only with SplitRouting) | +| th1.end.nc | End state soil moisture — other — layer 1 | +| th2.end.nc | End state soil moisture — other — layer 2 | +| th3.end.nc | End state soil moisture — other — layer 3 | +| thf1.end.nc | End state soil moisture — forest — layer 1 | +| thf2.end.nc | End state soil moisture — forest — layer 2 | +| thf3.end.nc | End state soil moisture — forest — layer 3 | +| thi1.end.nc | End state soil moisture — irrigation — layer 1 | +| thi2.end.nc | End state soil moisture — irrigation — layer 2 | +| thi3.end.nc | End state soil moisture — irrigation — layer 3 | +| uz.end.nc | End state upper groundwater zone — other | +| uzf.end.nc | End state upper groundwater zone — forest | +| uzi.end.nc | End state upper groundwater zone — irrigation | diff --git a/docs/3_step5_model-cold-warm-start-runs/index.md b/docs/3_step5_model-cold-warm-start-runs/index.md index 43ae463c..30a0ef08 100644 --- a/docs/3_step5_model-cold-warm-start-runs/index.md +++ b/docs/3_step5_model-cold-warm-start-runs/index.md @@ -2,13 +2,13 @@ > **!Reminder!** Types of OS LISFLOOD model runs and their purpose: ->**OS LISFLOOD prerun** simulation has the purpose to adequately initialize the state of the slow storages, namely grounwater zone and soil. OS LISFLOOD prerun constitutes the **initialization run**. OS LISFLOOD prerun output is used as input to the OS LISFLOOD cold start run. +>**OS LISFLOOD prerun** simulation has the purpose to adequately initialize the state of the slow storages, namely groundwater zone and soil. OS LISFLOOD prerun constitutes the **initialization run**. OS LISFLOOD prerun output is used as input to the OS LISFLOOD cold start run. ->OS LISFLOOD cold start run and warm start run deliver the actual model outputs to be usef for analysis/forecasts. +>OS LISFLOOD cold start run and warm start run deliver the actual model outputs to be used for analysis/forecasts. ->**OS LISFLOOD cold start** run takes as input the OS LISFLOOD prerun output to initialize the slow storages (soil and groundwater). Initial values of fast(er) respoding storages (e.g. channel volume) are set to bogus values. It is always recommended to discard the initial (3) years of the OS LISFLOOD cold start to allow adequate initialization of fast(er) respoding storages. +>**OS LISFLOOD cold start** run takes as input the OS LISFLOOD prerun output to initialize the slow storages (soil and groundwater). Initial values of fast(er) responding storages (e.g. channel volume) are set to bogus values. It is always recommended to discard the initial (3) years of the OS LISFLOOD cold start to allow adequate initialization of fast(er) responding storages. ->**OS LISFLOOD warm start** resumes the computations from the end states of a preceeding simulation. +>**OS LISFLOOD warm start** resumes the computations from the end states of a preceding simulation. ## Setting-up a OS LISFLOOD cold start simulation @@ -17,7 +17,7 @@ Running a OS LISFLOOD cold start simulation requires the following settings: ```xml - ``` > Note that the option Reminder: prerun, cold start, and warm start simulations must always share the same set of parameters. @@ -173,37 +159,37 @@ You can use either state maps or end maps as the initial conditions for a succee ``` -2) **Using state/end maps** +**Using state/end maps** LISFLOOD warm start is managed by two keys in Settings XML file: - "StepStart" which is the first output step/date from LISFLOOD model (forecast); - "timestepInit" which is the step/date to use as the initial state (one model step before "StepStart"). -3) Two different settings are used to **warm start LISFLOOD** if using dates in Settings XML file; or if using steps numbers in Settings XML file: +Two different settings are used to **warm start LISFLOOD** if using dates in Settings XML file; or if using steps numbers in Settings XML file: - **Option 1 - Using timestamps (dates) with State files:** +**Option 1 - Using timestamps (dates) with State files:** - CalendarDayStart = any timestamp before or equal to first output timestamp (date) (forecast); it is usually the same as StepStart (i.e. 2015-01-10 12:00) +CalendarDayStart = any timestamp before or equal to first output timestamp (date) (forecast); it is usually the same as StepStart (i.e. 2015-01-10 12:00) - StepStart= timestamp of first output (forecast) (i.e. 2015-01-10 12:00) +StepStart= timestamp of first output (forecast) (i.e. 2015-01-10 12:00) - timestepInit= timestamp of the step just before first model output (forecast) (i.e. 2015-01-10 06:00) +timestepInit= timestamp of the step just before first model output (forecast) (i.e. 2015-01-10 06:00) - If "CalendarDayStart" is set to 2015-01-10 12:00 and "StepStart" is set to 2015-01-10 12:00, the first output of the model will be marked 2015-01-10 12:00 and all netCDF state files will be stored using CalendarDayStart as time_unit with "time" array starting with [0]. +If "CalendarDayStart" is set to 2015-01-10 12:00 and "StepStart" is set to 2015-01-10 12:00, the first output of the model will be marked 2015-01-10 12:00 and all netCDF state files will be stored using CalendarDayStart as time_unit with "time" array starting with [0]. - To warm start LISFLOOD for a 6-hourly simulation with first output on 2015-01-10 12:00, state variables values for 2015-01-10 06:00 must be used to initialize the model, so "timestepInit" must be set to 2015-01-10 06:00. +To warm start LISFLOOD for a 6-hourly simulation with first output on 2015-01-10 12:00, state variables values for 2015-01-10 06:00 must be used to initialize the model, so "timestepInit" must be set to 2015-01-10 06:00. - **Option 2 - Using timesteps (step numbers) with State files:** +**Option 2 - Using timesteps (step numbers) with State files:** - CalendarDayStart = timestamp of first model output (forecast) +CalendarDayStart = timestamp of first model output (forecast) - StepStart=1 +StepStart=1 - timestepInit=0 +timestepInit=0 - Step numbers in LISFLOOD are always referred to "CalendarDayStart". If "CalendarDayStart" is 2015-01-10 12:00 and "StepStart" is 1, this means that the first output of the model will be at 2015-01-10 12:00 and all netCDF state files will be now stored using "hours since 2015-01-10 12:00" as time_unit and "time" array starting with [0]. The first step in NetCDF state files stored by this run, will be the same as CalendarDayStart, 2015-01-10 12:00. +Step numbers in LISFLOOD are always referred to "CalendarDayStart". If "CalendarDayStart" is 2015-01-10 12:00 and "StepStart" is 1, this means that the first output of the model will be at 2015-01-10 12:00 and all netCDF state files will be now stored using "hours since 2015-01-10 12:00" as time_unit and "time" array starting with [0]. The first step in NetCDF state files stored by this run, will be the same as CalendarDayStart, 2015-01-10 12:00. - To warm start LISFLOOD for a 6-hourly simulation with first output on 2015-01-10 12:00 (step #1), state variables values for 2015-01-10 06:00 must be used to initialize the model, so "timestepInit" must be set to 0. +To warm start LISFLOOD for a 6-hourly simulation with first output on 2015-01-10 12:00 (step #1), state variables values for 2015-01-10 06:00 must be used to initialize the model, so "timestepInit" must be set to 0. > NOTE: If State files are used to initialize LISFLOOD model run, LISFLOOD will automatically use timestamps in NetCDF files to get data for "timestepInit". If End files are used, LISFLOOD will automatically assign data from NetCDF to "timestepInit". diff --git a/docs/3_step7_command-line-flags/index.md b/docs/3_step7_command-line-flags/index.md index 8e94474d..73c0dca9 100644 --- a/docs/3_step7_command-line-flags/index.md +++ b/docs/3_step7_command-line-flags/index.md @@ -16,7 +16,7 @@ LISFLOOD command line takes the following flags as additional arguments after th The flags are utility flags and do not change the behaviour/parameters of the model. Here are the operational details of each flag. - **-q --quiet output progression given as .** - The default on-screen output of the lisflood command is the step count and the date/time of each computational step (each step being the run of all the activated modules in sequence for each time step). By setting this "-q" flag only a dot "." will be writtend on stdout for each computational step. + The default on-screen output of the lisflood command is the step count and the date/time of each computational step (each step being the run of all the activated modules in sequence for each time step). By setting this "-q" flag only a dot "." will be written on stdout for each computational step. - **-v --veryquiet no output progression is given** The default on-screen output of the lisflood command is the step count and the date/time of each computational step (each step being the run of all the activated modules in sequence for each time step). By setting this "-v" flag there will be no output written on stdout showing the model progression. Warnings will still printed out. diff --git a/docs/4_Static-Maps-introduction/index.md b/docs/4_Static-Maps-introduction/index.md index e370222e..c7474919 100644 --- a/docs/4_Static-Maps-introduction/index.md +++ b/docs/4_Static-Maps-introduction/index.md @@ -21,14 +21,14 @@ This user guide provides the examples for the European and Global domains that a ## References -Readers of this user guide are encouarged to cite the scinetific publications listed below. +Readers of this user guide are encouraged to cite the scientific publications listed below. - LISFLOOD Static Maps: Choulga, M., Moschini, F., Mazzetti, C., Grimaldi, S., Disperati, J., Beck, H., Salamon, P., and Prudhomme, C.: Technical note: Surface fields for global environmental modelling, Hydrol. Earth Syst. Sci., 28, 2991–3036, https://doi.org/10.5194/hess-28-2991-2024, 2024. Nevertheless, it must be noted this user guide provides the most updated and complete documentation about the maps and tables required for the implementation of OS LISFLOOD simulations. Users of OS LISFLOOD are encouraged to refer to this online documentation. Inaccuracies and errors can be reported by opening a [GitHub issue](https://github.com/ec-jrc/lisflood-code/issues). -- Pan-European Meterological input data: Salamon, P., Sperzel, T., Gomes, G. R., Radke-Fretz, M., Lemke, C.-D., Russo, C., Schweim, C., Zsoter, E., Dosio, A., Vomero, M., Ziese, M., and Grimaldi, S.: EMO-1: an improved version of the high-resolution multi-variable gridded meteorological dataset for Europe, Earth Syst. Sci. Data Discuss. [preprint], https://doi.org/10.5194/essd-2025-723, in review, 2026 +- Pan-European Meteorological input data: Salamon, P., Sperzel, T., Gomes, G. R., Radke-Fretz, M., Lemke, C.-D., Russo, C., Schweim, C., Zsoter, E., Dosio, A., Vomero, M., Ziese, M., and Grimaldi, S.: EMO-1: an improved version of the high-resolution multi-variable gridded meteorological dataset for Europe, Earth Syst. Sci. Data Discuss. [preprint], https://doi.org/10.5194/essd-2025-723, in review, 2026 @@ -40,6 +40,6 @@ OS LISFLOOD static input maps and tables for the operational versions of the [Co - EC-JRC Data Catalogue, [LISFLOOD static and parameter maps for GloFAS](https://data.jrc.ec.europa.eu/dataset/68050d73-9c06-499c-a441-dc5053cb0c86) -The European Meteorological Observations (EMO) 1 arcmin-resolution, (sub-)daily, multi-variable gridded meteorological dataset includes precipitation, temperatuure, wind speed,solar radiation and water vapour pressure for the pan-European EFAS computational domain, and it can be downloaded from: +The European Meteorological Observations (EMO) 1 arcmin-resolution, (sub-)daily, multi-variable gridded meteorological dataset includes precipitation, temperature, wind speed,solar radiation and water vapour pressure for the pan-European EFAS computational domain, and it can be downloaded from: - EC-JRC Data Catalogue, [EMO: A high-resolution multi-variable gridded meteorological data set for Europe](https://data.jrc.ec.europa.eu/dataset/0bd84be4-cec8-4180-97a6-8b3adaac4d26) \ No newline at end of file diff --git a/docs/4_Static-Maps_channel-geometry/index.md b/docs/4_Static-Maps_channel-geometry/index.md index 309ae74c..02430641 100644 --- a/docs/4_Static-Maps_channel-geometry/index.md +++ b/docs/4_Static-Maps_channel-geometry/index.md @@ -36,7 +36,7 @@ Channel characteristics, explained above, are shown in the Figure 41 below.
Type: Float32| Units: mm;
Range: ≥ 50**|Forested/ other (non-forested) area soil depth
for soil layer 1 (surface layer)/ 2 (middle layer)/ 3 (bottom layer)| +|Soil depth|soildepth**N_T**.nc;
Type: Float32| Units: mm;
Range: ≥ 50**|Forested/ other (non-forested) area soil depth
for soil layer 1 (superficial layer)/ 2 (upper layer)/ 3 (lower layer)| -*where **N** is the number of soil depth layer (**N**= ’1’ for surface layer, **N** = ’2’ for middle layer, **N** = ’3’ for bottom layer), and **T** is the landcover type (**T** = ’f’ for forested areas, **T** = ’o’ for non-forested areas or others). -**where range for soil layer 1 (surface layer) equals 50 mm, and for soil layer 2 (middle layer) and 3 (bottom layer) equals ≥ 50 mm. +*where **N** is the number of soil depth layer (**N**= ’1’ for superficial layer, **N** = ’2’ for upper layer, **N** = ’3’ for lower layer), and **T** is the landcover type (**T** = ’f’ for forested areas, **T** = ’o’ for non-forested areas or others). +**where range for soil layer 1 (superficial layer) equals 50 mm, and for soil layer 2 (upper layer) and 3 (lower layer) equals ≥ 50 mm. | Source data| Access |Temporal coverage|Spatial information| | :---| :--- | :--- | :---| @@ -163,16 +163,16 @@ The LISFLOOD model does not accept missing values for Kc, Kg and Km thus all zer ### Methodology -The methodology for the computation of the depth of the three soil layers has been adapted from [Burek et al., 2014](https://ec-jrc.github.io/lisflood/pdfs/Dataset_hydro.pdf). Here, total soil depth is taken as the 'absolute depth to bedrock' from [SoilGrids250m (2017)](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0169748) and 'root depth' for the fractions forest and non-forest is computed following methodology explained [above](../4_Static-Maps_land-use-depending#crop-coefficient,-crop-group-number,-manning’s-surface-roughness-coefficient-for-forest,-irrigated-crops-and-other-land-use-type-maps). Soil depth is expressed in mm.
-Soil depth layer 1 (surface) for forest/non-forest ($SD_1$) is assumed constant, equal to 50 mm all over the world: +The methodology for the computation of the depth of the three soil layers has been adapted from [Burek et al., 2014](https://ec-jrc.github.io/lisflood/pdfs/Dataset_hydro.pdf). The total soil depth is taken as the minimum between the 'absolute depth to bedrock' from [SoilGrids250m (2017)](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0169748) and the groundwater table depth from [Fan et al.2013](https://www.science.org/doi/10.1126/science.1229881). The 'root depth' for the fractions forest and non-forest is computed following methodology explained [above](../4_Static-Maps_land-use-depending#crop-coefficient,-crop-group-number,-manning’s-surface-roughness-coefficient-for-forest,-irrigated-crops-and-other-land-use-type-maps). Soil depth is expressed in mm.
+Soil depth layer 1 (superficial) for forest/non-forest ($SD_1$) is assumed constant, equal to 50 mm all over the world: $$ SD_1 = 50 mm $$ -Soil depth layers 2 (middle, $SD_2$) and 3 (bottom, $SD_3$) for forest/non-forest are computed in several steps – first at native resolution of the input dataset, then at required resolution. First step is following: +Soil depth layers 2 (upper, $SD_2$) and 3 (lower, $SD_3$) for forest/non-forest are computed in several steps – first at native resolution of the input dataset, then at required resolution. First step is following: -+ for soil depth layer 2 (middle, $SD_2$) ++ for soil depth layer 2 (upper, $SD_2$) | Absolute depth to bedrock | Equation | | :---| :--- | @@ -181,7 +181,7 @@ Soil depth layers 2 (middle, $SD_2$) and 3 (bottom, $SD_3$) for forest/non-fores If the computed value of $SD_2$ is lower than 50mm, then it is used $SD_2$ = $50 mm$ (in order to account for data uncertainty). -+ for soil depth layer 3 (bottom layer, $SD_3$) ++ for soil depth layer 3 (lower layer, $SD_3$) $$ SD_3 = absolutedepth - (SD_1 +SD_2) diff --git a/docs/4_Static-Maps_land-use/index.md b/docs/4_Static-Maps_land-use/index.md index 612bf241..c36ba70f 100644 --- a/docs/4_Static-Maps_land-use/index.md +++ b/docs/4_Static-Maps_land-use/index.md @@ -110,15 +110,15 @@ Note: Forest fraction field should be checked for consistency with all other fra | Source data| Reference/preparation | Temporal coverage | Spatial information | | :---| :--- | :--- | :--- | -|Spatial Production Allocation Model (SPAM) - Global Spatially-Disaggregated Crop Production Statistics Data for 2010 (V 1.0) |[Spatial Production Allocation Model](https://dataverse.harvard.edu/dataset.xhtml?persistentId=doi:10.7910/DVN/PRFF8V) |2018 |Global, 5 arcmin (approx 10 km)| +|FAO Global Map of Irrigation Areas v5.0 |[Siebert et al, 2013](https://openknowledge.fao.org/server/api/core/bitstreams/02e5f498-eb5d-4a08-b501-b3e05fdefc57/content) |2005 |Global, 5arcmin| |CORINE Land Cover 2018 CLC2018 |[CLC2018 ](https://land.copernicus.eu/pan-european/corine-land-cover) |2018 |European, 100 m| ### Methodology To create the fraction of irrigated crops map, multiple data sources can be used, for example when more accurate information could be found regionally compared with a global dataset. We describe here the process when using two datasets.
-For a global coverage, the 'spam2010v1r0_global_physical-area_CROP_i' files from the SPAM dataset are used. They describe the area (in hectares) where each crop is grown (one file per crop), not considering how often its production is harvested, with 'i' denoting a portion of the crop is irrigated. The area of all irrigated crops globally (except rice – modelled separately) is summed and resulting values translated from hectares to fractions per grid-cell, and the native resolution is changed to the highest resolution of all datasets used, here CORINE dataset 100 m resolution.
+For global coverage, the FAO Global Map of Irrigation Areas v5.0 showig the amount of area equipped for irrigation around the year 2005 in percentage of the total area could be used. For a regional coverage (here Europe), the '212' - ‘Permanently irrigated land, excluding rice’ value from the CORINE dataset is used (discrete classification where each grid-cell is fully covered with a certain land cover), assigning grid-cells covered with irrigated crops fraction 1.
-Finally, the generated fields are merged, with priority given to the high quality dataset (here from CORINE) over its geographical domain (here over the European domain), and the merged field resolution is reduced to the needed resolution, e.g. 1 arc min, with mean() reducer.
+The generated fields are merged, with priority given to the high quality dataset (here from CORINE) over its geographical domain (here over the European domain), and the merged field resolution is reduced to the needed resolution, e.g. 1 arc min, with mean() reducer.
Note: Irrigated crops fraction field should be checked for consistency with all other fractions. ### Results (example) @@ -177,7 +177,7 @@ Note: Irrigated rice fraction field should be checked for consistency with all o | :---| :--- | :--- | :--- | |Fraction of inland water|It can be prepared by implementing [this methodology](../4_Static-Maps_land-use#fraction-of-inland-water)|NA|Global| |Fraction of sealed surfaces|It can be prepared by implementing [this methodology](../4_Static-Maps_land-use#fraction-of-sealed-surfaces)|NA|Global| -|Fraction of forest|It can be prepared by implementing [this methodology](../4_Static-Maps_land-use#fraction-of-forest)|NA|Glonbal| +|Fraction of forest|It can be prepared by implementing [this methodology](../4_Static-Maps_land-use#fraction-of-forest)|NA|Global| |Fraction of irrigated crops|It can be prepared by implementing [this methodology](../4_Static-Maps_land-use#fraction-of-irrigated-crops)|NA|Global| |Fraction of rice|It can be prepared by implementing [this methodology](../4_Static-Maps_land-use#fraction-of-rice-crops)|NA|Global| diff --git a/docs/4_Static-Maps_reservoirs-lakes/index.md b/docs/4_Static-Maps_reservoirs-lakes/index.md index 77d4f8cc..bdde1f94 100644 --- a/docs/4_Static-Maps_reservoirs-lakes/index.md +++ b/docs/4_Static-Maps_reservoirs-lakes/index.md @@ -19,8 +19,8 @@ The lake mask map represents the area covered by lakes and reservoirs, it is use | Source data| Reference/preparation | Temporal coverage | Spatial information | | :---| :--- | :--- | :--- | |Global Lakes and Wetlands Database (GLWD):
Large Lake Polygons (Level 1) |[GLWD leve1](https://www.worldwildlife.org/publications/global-lakes-and-wetlands-database-large-lake-polygons-level-1)|2004|Global, 1:1 to 1:3 million resolution| -|Global Lakes and Wetlands Database (GLWD):
Small Lake Polygons (Level 3) |[GLWD leve1](https://www.worldwildlife.org/publications/global-lakes-and-wetlands-database-large-lake-polygons-level-2)|2004|Global, 1:1 to 1:3 million resolution| -|Fraction of inland water| It can be prepared by using
the methodology explained [here](../4_Static-Maps_land-use#lend-use)|NA|Global| +|Global Lakes and Wetlands Database (GLWD):
Small Lake Polygons (Level 2) |[GLWD leve1](https://www.worldwildlife.org/publications/global-lakes-and-wetlands-database-large-lake-polygons-level-2)|2004|Global, 1:1 to 1:3 million resolution| +|Fraction of inland water| It can be prepared by using
the methodology explained [here](../4_Static-Maps_land-use#land-use)|NA|Global| ### Methodology @@ -42,7 +42,7 @@ If a grid-cell has any fraction of inland water and is inside the GLWD Level 1 a ## Reservoirs map and tables Reservoirs are identified using a unique integer number (ID). -The reservoirs map shows the outflow location of each reservoir: each outflow point has the ID of the relevant reservoir. Modelling of reservoirs within OS LISFLOOD then requires the following pieces of information: reservoir storage, minimum reservoir outflow, normal reservoir outflow, flood reservoir outflow (connected to 100 year return period discharge). The latter information is provuided to the code in .txt format (these txt files are traditionally called OS LISFLOOD tables). +The reservoirs map shows the outflow location of each reservoir: each outflow point has the ID of the relevant reservoir. Modelling of reservoirs within OS LISFLOOD then requires the following pieces of information: reservoir storage, minimum reservoir outflow, normal reservoir outflow, flood reservoir outflow (connected to 100 year return period discharge). The latter information is provided to the code in .txt format (these txt files are traditionally called OS LISFLOOD tables). ### General map and tables information and possible source data @@ -51,8 +51,8 @@ The reservoirs map shows the outflow location of each reservoir: each outflow po |Reservoirs|res.nc;
Type: Float32|Units: -;
Range: integer ID number to identify each lake |Reservoir outflow location
(stores lake ID number in the metadata file)| |Reservoir Total Storage| res_storage.txt;
2 columms: ID VALUE; 1 row for each reservoir|Units: m3|Reservoir capacity| |Reservoir Flood outflow| res_flood_outflow.txt;
2 columms: ID VALUE; 1 row for each reservoir|Units: m3/s|Reservoir Flood outflow| -|Reseervoir normal outflow| res_normal_outflow.txt;
2 columms: ID VALUE; 1 row for each reservoir|Units: m3/s|Normal outflow| -|Reseervoir minimum outflow| res_min_outflow.txt;
2 columms: ID VALUE; 1 row for each reservoire|Units: m3/s|Minimum outlfow| +|Reservoir normal outflow| res_normal_outflow.txt;
2 columms: ID VALUE; 1 row for each reservoir|Units: m3/s|Normal outflow| +|Reseervoir minimum outflow| res_min_outflow.txt;
2 columms: ID VALUE; 1 row for each reservoir|Units: m3/s|Minimum outflow| The well-known Global Reservoir and Dam Database[GDW](https://www.globaldamwatch.org/grand) now superseeded by the Global Dam Watch [GDW](https://www.globaldamwatch.org/database) is a relevant example of source of data for lakes map and tables. @@ -61,7 +61,7 @@ As a first step, it is recommended to create a file including all reservoir info Essential information are: 1. reservoir unique identifier, selected by the user or taken from external datasets; -2. Geographic oordinates of the reservoir outlet; +2. Geographic coordinates of the reservoir outlet; 3. Coordinates of the reservoir outlet mapped on OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)); 4. Reservoir storage capacity; 5. Reservoir normal outflow; @@ -82,23 +82,23 @@ Optional metadata are: The following paragraphs provide guidelines for the generation of the reservoir map and tables. -Reservoir unique identifier (1) and coordinates of the outlet mapped on the OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) (3) are required to generate the reservoirs map. Geographic oordinates of the reservoirs outlet (2) and OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) are essential to generate (3). Adequate model representation requires the agreement between reservoir catchment area (7) and OS LISFLOOD [upstream area map](../4_Static-Maps_topography/index.md). +Reservoir unique identifier (1) and coordinates of the outlet mapped on the OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) (3) are required to generate the reservoirs map. Geographic coordinates of the reservoirs outlet (2) and OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) are essential to generate (3). Adequate model representation requires the agreement between reservoir catchment area (7) and OS LISFLOOD [upstream area map](../4_Static-Maps_topography/index.md). -Reservoir storage capcaity can be retrieved from local datasets or global datasets such as [GDW](https://www.globaldamwatch.org/grand). +Reservoir storage capacity can be retrieved from local datasets or global datasets such as [GDW](https://www.globaldamwatch.org/grand). -Reservoir normal outflow, minimum outflow, flood outflow can also be derived from in situ observations, local datasets or global datasets. Where such information is not avaible, users can implement the following approximations: reservoir normal outflow can be approximated by river average discharge (from measurements or numerical simulations); reservoir minimum outflow can be approximated by environmental discharge (from regulations or numerical approximation); resrervoir flood outflow can be approaximated by 100-year return period of river discharge discharge. +Reservoir normal outflow, minimum outflow, flood outflow can also be derived from in situ observations, local datasets or global datasets. Where such information is not available, users can implement the following approximations: reservoir normal outflow can be approximated by river average discharge (from measurements or numerical simulations); reservoir minimum outflow can be approximated by environmental discharge (from regulations or numerical approximation); reservoir flood outflow can be approximated by 100-year return period of river discharge. -The degree of regulation can be computes as the quotient between reservoir capacity (Units: MCM) and normal reservoir outflow (units: m3/s). It is recommented to model reservoirs with low degree of regulation (e.g. lower than 0.08) as lakes. +The degree of regulation can be computed as the quotient between reservoir capacity (Units: MCM) and normal reservoir outflow (units: m3/s). It is recommended to model reservoirs with low degree of regulation (e.g. lower than 0.08) as lakes. Reservoir maps and tables of the European 1arcmin domain and global 3arcmin domain are mainly based on information from [GDW](https://www.globaldamwatch.org/grand). Reservoirs included in the European 1arcmin domain had a minimum volume of 10 hm3, a minimum upstream catchment area of 50 km2, degree of regulation larger or equal to 0.08. Lakes included in the global 3arcmin domain had a minimum volume of 100 hm3, a minimum upstream catchment area of 250 km2, degree of regulation larger or equal to 0.08. -Reservoir normal, nminimum, flood outflow were computed using OS LISFLOOD CEMS EFAS and CEMS GloFAS discharge reanalysis (GloFASv4 reanalysis upstream of the reservoir for GloFASv5 tables; EFASv5 naturalized flow simulation for EFASv6 tables). +Reservoir normal, minimum, flood outflow were computed using OS LISFLOOD CEMS EFAS and CEMS GloFAS discharge reanalysis (GloFASv4 reanalysis upstream of the reservoir for GloFASv5 tables; EFASv5 naturalized flow simulation for EFASv6 tables). ## Lakes map and tables Lakes are identified using a unique integer number (ID). -The lakes map shows the outflow location of each lake: each outflow point has the ID of the relevant lake. Modelling of lakes within OS LISFLOOD then requires the following pieces of information: lake surface area, average inflow to the lake, width of the lake outlet. The latter information is provuided to the code in .txt format (these txt files are traditionally called OS LISFLOOD tables). +The lakes map shows the outflow location of each lake: each outflow point has the ID of the relevant lake. Modelling of lakes within OS LISFLOOD then requires the following pieces of information: lake surface area, average inflow to the lake, width of the lake outlet. The latter information is provided to the code in .txt format (these txt files are traditionally called OS LISFLOOD tables). ### General map and tables information and possible source data @@ -118,7 +118,7 @@ As a first step, it is recommended to create a file including all lakes informat Essential information are: 1. Lake unique identifier, selected by the user or taken from external datasets; -2. Geographic oordinates of the lake outlet; +2. Geographic coordinates of the lake outlet; 3. Coordinates of the lake outlet mapped on OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)); 4. Lake surface area; 5. Lake outlet width; @@ -135,11 +135,11 @@ Optional metadata are: The following paragraphs provide guidelines for the generation of the lake map and tables. -Lake unique identifier (1) and coordinates of the outlet mapped on the OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) (3) are required to generate the lake map. Geographic oordinates of the lake outlet (2) and OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) are essential to generate (3). Adequate model representation requires the agreement between lake catchment area (7) and OS LISFLOOD [upstream area map](../4_Static-Maps_topography/index.md). +Lake unique identifier (1) and coordinates of the outlet mapped on the OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) (3) are required to generate the lake map. Geographic coordinates of the lake outlet (2) and OS LISFLOOD local drainage direction map ([ldd](../4_Static-Maps_topography/index.md)) are essential to generate (3). Adequate model representation requires the agreement between lake catchment area (7) and OS LISFLOOD [upstream area map](../4_Static-Maps_topography/index.md). Lake surface area can be retrieved from local datasets or global datasets such as HydroLAKES](https://www.hydrosheds.org/products/hydrolakes), [GLWD](https://www.hydrosheds.org/products/glwd), [GRAND](https://www.globaldamwatch.org/grand). -Where lake outlet width cannot be retrieved from external datdaset, it can be measured with GIS tools. +Where lake outlet width cannot be retrieved from external dataset, it can be measured with GIS tools. Finally, lake average inflow can be retrieved from observed time series (where available) or numerical model results. diff --git a/docs/4_Static-Maps_rice-calendar/index.md b/docs/4_Static-Maps_rice-calendar/index.md index f10beae7..0750679f 100644 --- a/docs/4_Static-Maps_rice-calendar/index.md +++ b/docs/4_Static-Maps_rice-calendar/index.md @@ -48,7 +48,7 @@ Then, the rice planting and harvesting fields for season 1 and 2 are created bas

-*Figure 55: Rice planting day 2 (season 2) map at 1 arc min horizontal resolution for European domain (left) and at 3 arc min horizontal resolution for Global domain (right).* +*Figure 56: Rice planting day 2 (season 2) map at 1 arc min horizontal resolution for European domain (left) and at 3 arc min horizontal resolution for Global domain (right).* diff --git a/docs/4_Static-Maps_soil-hydraulic-properties/index.md b/docs/4_Static-Maps_soil-hydraulic-properties/index.md index cac0fdd1..32e7b6d6 100644 --- a/docs/4_Static-Maps_soil-hydraulic-properties/index.md +++ b/docs/4_Static-Maps_soil-hydraulic-properties/index.md @@ -33,12 +33,12 @@ The table below lists the data required for the implementation of the PTFs propo | Source data| Reference/preparation | Temporal coverage | Spatial information | | :---| :--- | :--- | :--- | -| % of Clay (C)|[ISRIC](https://files.isric.org/soilgrids/latest/data/clay/), mean value |2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| -| % of Silt (S)|[ISRIC](https://files.isric.org/soilgrids/latest/data/silt/), - |2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| -| % organic carbon (OC)|[ISRIC](https://files.isric.org/soilgrids/latest/data/soc/), mean value|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| -| Bulk Density (BD)|[ISRIC](https://files.isric.org/soilgrids/latest/data/bdod/), median value (Q0.5)|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| -| Soil PH |[ISRIC](https://files.isric.org/soilgrids/latest/data/phh2o/), mean value|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| -| Cation exchange capacity (CEC)|[ISRIC](https://files.isric.org/soilgrids/latest/data/cec/), mean value|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| +| % of Clay (C)|[ISRIC SoilGrids250 2.0](https://files.isric.org/soilgrids/latest/data/clay/), [Poggio et al. (2021)](https://soil.copernicus.org/articles/7/217/2021/soil-7-217-2021.html), mean value |2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| +| % of Silt (S)|[ISRIC SoilGrids250 2.0](https://files.isric.org/soilgrids/latest/data/silt/), [Poggio et al. (2021)](https://soil.copernicus.org/articles/7/217/2021/soil-7-217-2021.html), - |2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| +| % organic carbon (OC)|[ISRIC SoilGrids250 2.0](https://files.isric.org/soilgrids/latest/data/soc/), [Poggio et al. (2021)](https://soil.copernicus.org/articles/7/217/2021/soil-7-217-2021.html), mean value|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| +| Bulk Density (BD)|ISRIC SoilGrids250 2.0](https://files.isric.org/soilgrids/latest/data/bdod/), [Poggio et al. (2021)](https://soil.copernicus.org/articles/7/217/2021/soil-7-217-2021.html), median value (Q0.5)|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| +| Soil PH |[ISRIC](https://files.isric.org/soilgrids/latest/data/phh2o/), [Poggio et al. (2021)](https://soil.copernicus.org/articles/7/217/2021/soil-7-217-2021.html), mean value|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| +| Cation exchange capacity (CEC)|[ISRIC SoilGrids250 2.0](https://files.isric.org/soilgrids/latest/data/cec/), [Poggio et al. (2021)](https://soil.copernicus.org/articles/7/217/2021/soil-7-217-2021.html), mean value|2020|Global, 250 m available depths (cm):
0-5, 5-15, 15-30, 30-60, 60-100, 100-200| | Soil depth map | It can be prepared by using the
methodology explained [here](../4_Static-Maps_land-use-depending)| NA | Global, 250 m | | Fraction of forested
areas map | It can be prepared by using the
methodology explained [here](../4_Static-Maps_land-use)| NA| Global, 100 m | diff --git a/docs/4_Static-Maps_topography/index.md b/docs/4_Static-Maps_topography/index.md index 391ddfae..ac115275 100644 --- a/docs/4_Static-Maps_topography/index.md +++ b/docs/4_Static-Maps_topography/index.md @@ -26,7 +26,7 @@ The upstream area in a distributed hydrological model is the accumulated area of It is suggested to use cautiously any file transforming commands as they might change file structure. Here it is suggested to use only CDO, GDAL and Python commands to preserve initial file structure as much as possible (especially latitude and longitude values) and be able to use it later as a Template for all other static maps.
To create a local drain direction (ldd) field from a flow direction map, initial file values in a NetCDF format are changed in the following way for different geographical directions. Mouth: ‘-1’=>’5’, Inland: ‘0’=>’5’, North: ‘1’=>’8’, NE: ‘2’=>’9’, East: ‘3’=>’6’, SE: ‘4’=>’3’, South: ‘5’=>’2’, SW: ‘6’=>’1’, West: ‘7’=>’4’, NW: ‘8’=>’7’.
-Note: Obtaining a flow direction map from a digital elevation model is a complex process and is not described here. A good example of how to create a flow direction map can be found in [Yamazaki et al. (WRR, 2019)](https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2019WR024873). Note also that the created ldd file must be checked and corrected if needed, so that water is not flowing out of the region of interest. These pages provide relevant information on the definition and preparation of a sound ldd: [lddrepair](https://pcraster.geo.uu.nl/pcraster/4.4.2/documentation/pcraster_manual/sphinx/op_lddrepair.html) and [lddmask](https://pcraster.geo.uu.nl/pcraster/4.4.2/documentation/pcraster_manual/sphinx/op_lddmask.html_). Expert users might want to check the usage of lddmask witih the OS LISFLOOD module [routing.py](https://github.com/ec-jrc/lisflood-code/blob/master/src/lisflood/hydrological_modules/routing.py). +Note: Obtaining a flow direction map from a digital elevation model is a complex process and is not described here. A good example of how to create a flow direction map can be found in [Yamazaki et al. (WRR, 2019)](https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/2019WR024873). Note also that the created ldd file must be checked and corrected if needed, so that water is not flowing out of the region of interest. These pages provide relevant information on the definition and preparation of a sound ldd: [lddrepair](https://pcraster.geo.uu.nl/pcraster/4.4.2/documentation/pcraster_manual/sphinx/op_lddrepair.html) and [lddmask](https://pcraster.geo.uu.nl/pcraster/4.4.2/documentation/pcraster_manual/sphinx/op_lddmask.html_). Expert users might want to check the usage of lddmask with the OS LISFLOOD module [routing.py](https://github.com/ec-jrc/lisflood-code/blob/master/src/lisflood/hydrological_modules/routing.py). Finally, after all manipulations of the NetCDF file, latitude and longitude values from the native files must be copied to the newly generated file to insure identical structure of all static map files.
### Results (example) diff --git a/docs/4_Static-Maps_water-use/index.md b/docs/4_Static-Maps_water-use/index.md index adeac0ca..ee5604c9 100644 --- a/docs/4_Static-Maps_water-use/index.md +++ b/docs/4_Static-Maps_water-use/index.md @@ -2,31 +2,29 @@ This chapter describes the main features of time variant (transient) sectoral water demand maps for domestic, livestock, industrial, energy (cooling) sectors. This chapter then focuses on the description of the ancillary maps required by OS LISFLOOD for the modelling of water abstraction from groundwater, surface water (channels, lakes, reservoirs), and non-conventional sources (e.g. desalination plants). -In this documentation, water demand is the amount of water required to meet the needs of the vaious uses. Water abstraction or water withdrawal (considered synonyms) is the amount of water to be abstracted from surface of groundwater resources to meet water demand requirements. Water abstraction/withdrawal is generally larger than water demand to account for leakages and other losses in the water supply system. Consumptive use is the water volume used and removed from the hydrological cycle. +In this documentation, water demand is the amount of water required to meet the needs of the various uses. Water abstraction or water withdrawal (considered synonyms) is the amount of water to be abstracted from surface or groundwater resources to meet water demand requirements. Water abstraction/withdrawal is generally larger than water demand to account for leakages and other losses in the water supply system. However, if the demand cannot be met, withdrawals are lower than the demand. Consumptive use is the actual water volume used and removed from the hydrological cycle. ## Sectoral water demand maps - Sectoral water demand maps indicate, for each pixel, the time-varying water demand value to supply for domestic, livestock, industrial, and thermoelectric water consumption. The segregation of the total water demand for anthropogenic use into four main sectors, namely domestic, energy, industrial and livestock water demand, enables a more accurate representation of the processes and follows the Food and Agriculture Organisation of the United Nations (FAO) terminology ([Kohli et al., 2012](https://openknowledge.fao.org/server/api/core/bitstreams/f18d9669-c967-4e37-b466-b7dc7ab78f8d/content)). Domestic water demand represents indoor and outdoor household water use as well as other uses (e.g. industrial and urban agriculture) connected to the municipal system (e.g. water use by shops, schools and public buildings). Electricity (energy) water demand is the water use for the cooling of thermoelectric and nuclear power plants. Water demand for industry is the water used for fabricating, processing, washing, cooling or transporting products and also includes water within the final products and water used for sanitation within the manufacturing facility. Livestock demand is the water used for drinking and cleaning purposes of livestock ([Choulga et al. 2024](https://hess.copernicus.org/articles/28/2991/2024/)). -The temporal discretization of these maps (e.g. daily, monthly, yearly update frequency) can be chosen by the modeller, mainly depending on the modelling purposes and on the available input data. Values must be expressed in $[\frac{mm}{day}]$, for any update frequency and for any modelling computational step. The usage of the data in case of frequency of update larger than one day (e.g. monthly updates) is described in [this section](https://ec-jrc.github.io/lisflood-model/2_18_stdLISFLOOD_water-use/) of the model documentation. Similarly to the meteorological forcings, OS LISFLOOD internally adjusts daily input values to the sub-daily modelling step. +The temporal discretization of these maps (e.g. daily, monthly, yearly update frequency) can be chosen by the modeller, mainly depending on the modelling purposes and on the available input data. Values must be expressed in $[\frac{mm}{day}]$, for any update frequency and for any modelling computational step. In case of frequencies larger than one day (e.g. monthly demand updates) is described in [this section](https://ec-jrc.github.io/lisflood-model/2_18_stdLISFLOOD_water-use/) of the model documentation. Similarly to the meteorological forcings, OS LISFLOOD internally adjusts daily input values to the sub-daily modelling step. -European 1arcmin and global 3arcmin sectoral water demand maps were generated using the OS LISFLOOD utility [water-demand-historical](https://github.com/ec-jrc/lisflood-utilities/tree/master/src/lisfloodutilities/water-demand-historic). -This user guide provides an overview of the protocol implemented to produce domestic and energy demand maps with values updated monthly, industrial and livestock demand maps with values updated yearly. The generation of the maps relies on a number of external datasets: the complete list of external datasets and step-wise instructions are provided in the readme of the OS LISFLOOD utility [water-demand-historcal](https://github.com/ec-jrc/lisflood-utilities/tree/master/src/lisfloodutilities/water-demand-historic). -[FAO AQUASTAT](https://www.fao.org/aquastat/en/) constitues the main source of information: specifically, country level data of water withdrawal. Therefore, it must be noted that, strictly speaking, these maps represent water withdrawal rather than water demand. As explained in this page, this discrepancy can be accounted for by adequately setting ancillary OS LISFLOOD inputs such as $leakage fraction$. +European 1 arcmin and global 3 arcmin sectoral water demand maps were generated using the OS LISFLOOD utility [water-demand-historical](https://github.com/ec-jrc/lisflood-utilities/tree/master/src/lisfloodutilities/water-demand-historic). +This user guide provides an overview of the protocol implemented to produce domestic and energy demand maps with values updated monthly, as well as industrial and livestock demand maps with values updated yearly. The generation of the maps relies on a number of external datasets: the complete list of external datasets and step-wise instructions are provided in the readme of the OS LISFLOOD utility [water-demand-historical](https://github.com/ec-jrc/lisflood-utilities/tree/master/src/lisfloodutilities/water-demand-historic). +[FAO AQUASTAT](https://www.fao.org/aquastat/en/) constitutes the main source of information: specifically, country level data of water withdrawal. Therefore, strictly speaking, these maps represent water withdrawal rather than water demand. As explained in this page, this discrepancy can be accounted for by adequately setting ancillary OS LISFLOOD inputs such as $leakage fraction$. -Domestic water withdrawal estimates rely on FAO AQUASTAT municipal water withdrawal estimate per country and per year. Spatial disaggregation is achieved based on population data ([Global Human Settlement Layer](https://human-settlement.emergency.copernicus.eu/index_op.php)). Temporal downscaling to monthly frequency relies on monthly air temperature grids (e.g. [MSWX, Beck et al., 2022](https://journals.ametsoc.org/view/journals/bams/103/3/BAMS-D-21-0145.1.xml)) and literature parameters ([Hunag et al., 2018](https://hess.copernicus.org/articles/22/2117/2018/)) +Domestic water withdrawal estimates rely on FAO AQUASTAT municipal water withdrawal estimate per country and per year. Spatial disaggregation is achieved based on population data ([Global Human Settlement Layer](https://human-settlement.emergency.copernicus.eu/index_op.php)). Temporal downscaling to monthly frequency relies on monthly air temperature grids (e.g. [MSWX, Beck et al., 2022](https://journals.ametsoc.org/view/journals/bams/103/3/BAMS-D-21-0145.1.xml)) and literature parameters ([Huang et al., 2018](https://hess.copernicus.org/articles/22/2117/2018/)) -Industrial and energy water withdrawal estimates are based on country-scale FAO AQUASTAT industrial withdrawal data, country-scale [World Bank](https://data.worldbank.org/) manufacturing value added (MVA) data, [Global Change Analysis Model, GCAM](https://github.com/JGCRI/gcam-core/releases) regional industry and thermoelectric withdrawals, datasets avaible in the literature (e.g. Global-scale gridded estimates of thermoelectric power and manufacturing water use by [Vassolo & Doll, 2005](https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2004WR003360)). Spatial downscaling is based on population grids (due to the lack of more precise data sources). Temporal downscaling of energy water withdrawal estimates rely on temperature information. +Industrial (yearly) and energy (monthly) water withdrawal estimates are based on country-scale FAO AQUASTAT industrial withdrawal data, country-scale [World Bank](https://data.worldbank.org/) manufacturing value added (MVA) data, [Global Change Analysis Model, GCAM](https://github.com/JGCRI/gcam-core/releases) regional industry and thermoelectric withdrawals, datasets available in the literature (e.g. Global-scale gridded estimates of thermoelectric power and manufacturing water use by [Vassolo & Doll, 2005](https://agupubs.onlinelibrary.wiley.com/doi/10.1029/2004WR003360)). Spatial downscaling is based on population grids (due to the lack of more precise data sources). Temporal downscaling of energy water withdrawal estimates rely on temperature information. -Country-scale livestock withdrawals estimates leverage on the difference between the FAO AQUASTAT data of agriculture and irrigation withdrawals, and on GCAM regional livestock withdrawals. Spatial downscaling is performed based on [Gridded Livestock of the World](https://www.nature.com/articles/sdata2018227). +Country-scale livestock withdrawals are based on country-level FAO AQUASTAT data (difference between agricolture and irrigation withdrawals, where available) and on regional GCAM livestock withdrawals (where FAO AQUASTAT data are not available). Spatial downscaling of regional GCAM livestock withdrawals to country level is performed based on country values provided in [Gridded Livestock of the World](https://www.nature.com/articles/sdata2018227). The protocol for the generation of water withdrawal maps relied on a number of assumptions due to the lack of homogenous and granular data at the continental and global scale. Even at the country scale, information is not available for all countries, and for all years. Gaps in space and time were filled using nearest-neighbor interpolation and linear interpolation, respectively. ### Groundwater bodies - -The map of groundwater bodies is a boolean map indicating the spatial distribution of groundwater exploitable resources: OS LISFLOOD allows abstraction from the lower groundwater zone only in pixels with value equal 1. +The map of groundwater bodies is a boolean map indicating the spatial distribution of groundwater exploitable resources: OS LISFLOOD allows abstraction from the lower groundwater zone only in pixels with values set to 1. This map can be generated using local, regional, continental, or global scale source data, depending on the specific OS LISFLOOD application. @@ -34,9 +32,9 @@ Examples of continental scale source data are (BGR & UNESCO) and [Africa Ground The [Groundwater Resources of the World](https://www.whymap.org/whymap/EN/Maps_Data/Gwr/gwr_node_en.html) of the World-wide Hydrogeological Mapping and Assessment Programme (WHYMAP) is an example of source data for the global domain. -Global 3 arcmin groundwater bodies map was produced leveraging on two datasets: [Groundwater Resources of the World](https://www.whymap.org/whymap/EN/Maps_Data/Gwr/gwr_node_en.html) and the global map of bedrock elevation [GDEMM2024](https://www.nature.com/articles/s41597-024-03920-x). Albeit the first dataset was specifcally derived to highlight exploitable groundwater resources, the use of GDEMM2024 was considered useful to ensure the consistency between the global map of groudwater bodies and the available information on country-level groundwater abstraction (more details in the section **Sectoral water demand maps**). It was decided to ensure the presence of at least one groundwater pixel in all countries that reported some groundwater abstraction. According to this approach, exploitable groudwater bodies in the global 3arcmin map have larger extent than the data shown in the Groundwater Resources of the World. It is of parmount importance to acknowledge the uncertainty of the source data for the generation of water withdrawal and releated maps: the first version of the global 3arcmin map prioritized the consistency with country level data of water withdrawal (**Sectoral water demand maps**). +Datasets such as [Groundwater Resources of the World](BGR - WHYMAP - Groundwater Resources of the World) and the global map of bedrock elevation [GDEMM2024](GDEMM2024: Global Digital Elevation Merged Model 2024 for surface, bedrock, ice thickness, and land…) could be used as source data of the Global 3 arcmin groundwater bodies map. GDEMM2024 was selected as source of the current version of the Global 3 arcmin groundwater bodies map to ensure the consistency between the global map of groundwater bodies and the available information on country-level groundwater abstraction (i.e. all countries with non-zero values of groundwater abstraction included at least one pixel classified as groundwater body) -European 1 arcmin groundwater bodies map was generated using the [International Hydrogeological Map of Europe, IHME1500](https://www.bgr.bund.de/EN/Themen/Grundwasser/Projekte/Flaechen-Rauminformationen/Ihme1500/ihme1500.html) v 1.2 as main data source. Specifically, groundwater resources were deemed available for the areas belonging to the following classes: *I. Predominally porous rocks; II. Predominnally fissured rocks, including karstified rocks; IIIa. Locally acquiferous rocks*. This approach satisfied the cross-check with available information on country level water abstraction from groundwater (for details, please see **Sectoral water demand maps**). +The European 1 arcmin groundwater bodies map was generated using the [International Hydrogeological Map of Europe, IHME1500](https://www.bgr.bund.de/EN/Themen/Grundwasser/Projekte/Flaechen-Rauminformationen/Ihme1500/ihme1500.html) v 1.2 as main data source. Specifically, groundwater resources were deemed available for the areas belonging to the following classes: *I. Predominantly porous rocks; II. Predominantly fissured rocks, including karstified rocks; IIIa. Locally aquiferous rocks*. This approach satisfied the cross-check with available information on country level water abstraction from groundwater (for details, please see **Sectoral water demand maps**). Groundwater bodies of areas of the European extended domain (as defined in the [introduction to the static maps](../4_Static-Maps-introduction/index.md)) not covered by IHME1500 were derived from the global map of groundwater bodies. To avoid abrupt discontinuities, the two datasets were merged at the country level. ### Fraction of water abstraction from groundwater, surface water, non-conventional resources @@ -46,13 +44,13 @@ Information is provided to the OS LISFLOOD code at the pixel level. However, the The fraction of water to be abstracted from groundwater, $fracgroundwateruse$, is computed in two subsequent steps. -The first step requires the computation of fracgroundwateruse of the ratio of water withdrawal from groundwater and total water widthdrawal, both quantities are aggreagated values over the same spatial domain (e.g. water region, country). +The first step requires the computation of $fracgroundwateruse$ based on the ratio of water withdrawal from groundwater to total water withdrawal, both quantities are aggregated values over the same spatial domain (e.g. water region, country). $$ fracgroundwateruse_1 = \frac{water withdrawal from groundwater}{total water withdrawal} $$ -$fracgroundwateruse_1$ represents then the average value for chosen spatial domain. +$fracgroundwateruse_1$ represents then the average value for the chosen spatial domain. Pixel values of $fracgroundwateruse$ must account for the proportion of exploitable groundwater resources within the spatial domain: $fracgroundwateruse$ must be zero in pixels with no exploitable groundwater resources, and fraction values in the remaining pixels must be adjusted accordingly. The second step is then defined as follows: $$ @@ -61,10 +59,10 @@ $$ $groundwaterbodies$ is the boolean with 1 values where groundwater is available. $area_T$ and $area_G$ are the total area of the spatial domain and the area with available groundwater within the spatial domain, respectively. -$fracnonconventionalwateruse$ is the fraction of water derived from non-conventional water sources (e.g. desalination) within the spatial domain. It is computed as the ratio of water withdrawal from groundwater and total water widthdrawal, as before, both quantities are aggreagated values over the same spatial domain (e.g. water region, country). +$fracnonconventionalwateruse$ is the fraction of water derived from non-conventional water sources (e.g. desalination) within the spatial domain. It is computed as the ratio of water withdrawal from groundwater and total water withdrawal, as before, both quantities are aggregated values over the same spatial domain (e.g. water region, country). $$ -fracnonconventionalwateruse = \frac{water withdrawal from non conventional sources}{total water withdrawal} +fracnonconventionalwateruse = \frac{water withdrawal from non conventional sources}{total water withdrawal} $$ Finally, the proportion of water demand to be satisfied by surface water resources is computed internally by OS LISFLOOD as: @@ -75,34 +73,34 @@ $$ Information of water withdrawal from the three sources must be retrieved from external datasets. -European 1arcmin and global 3arcmin maps were generated levaraging on country level information made available from [FAO AQUASTAT](https://www.fao.org/aquastat/en/). Data were retrieved in 2024: the most recent information referred to the year 2021. +European 1 arcmin and global 3 arcmin maps were generated leveraging on country level information made available from [FAO AQUASTAT](https://www.fao.org/aquastat/en/). Data were retrieved in 2024: the most recent information at that time referred to the year 2021. The database provides information at the country level, nevertheless, information is not available for all countries, and different variables are available for different countries. -The implementented methdology aimed to maximize the exploitation of available information. -Total water withdrawal was either directly provided or defined as the sum of the other available infomration (surface water abstraction, groundwater abstraction, desalinated water, treated waste water, reuse of drained waeter from agricoluture, https://www.fao.org/aquastat/en/databases/glossary/). Groundwater withdrawal was either directly provided or computed as the complementary of the sum of the other variables. -Despite the attempt to maximize the exploitation of FAO AQUASTAT information, fraction of groundwater use could not be computed for some countries. The filling was done based on nearest neighbour approach. To avoid enforcing "extreme" scenarios to countries with no info, only values in the interval [0.15, 0.85] were transferred from the closest neighbors. If the three closest countries did not have information or had values outside of the interval [0.15, 0.85], the fill value was 0.5. -When using FAO AQUASTAT database, water withdrawal from non conventional sources was defined equal to the variable 'desalinated water produced'. Conutries were the latter variable was not availeble were allocated 0 value of $fractionofnonconventional$ water use. It is here noted that this water source is "outside" of the hydrological cycle modelled by LISFLOOD (oceans are not modelled!). Desalination plants processing water of lakes in landlocked countries are, on the contrary, retrieving water from the hydrological cycle modelled by LISFLOOD: to be consistent with the model implementation, the latter quantied did not contribute to the computation of $fractionofnonconventional$ water use, but were added to the abstraction from surface water bodies. +The implemented methdology aimed to maximize the exploitation of available information. +Total water withdrawal was either directly provided or defined as the sum of the other available information (surface water abstraction, groundwater abstraction, desalinated water, treated waste water, reuse of drained water from agricluture, https://www.fao.org/aquastat/en/databases/glossary/). Groundwater withdrawal was either directly provided or computed as the complementary of the sum of the other variables. +Despite the attempt to maximize the exploitation of FAO AQUASTAT information, fraction of groundwater use could not be computed for some countries. The filling was done based on a nearest neighbour approach. To avoid enforcing "extreme" scenarios to countries with no info, only values in the interval [0.15, 0.85] were transferred from the closest neighbors. If the three closest countries did not have information or had values outside of the interval [0.15, 0.85], the fill value was 0.5. +When using FAO AQUASTAT database, water withdrawal from non conventional sources was defined equal to the variable 'desalinated water produced'. Countries where the latter variable was not available were allocated 0 value of $fractionofnonconventional$ water use. It is here noted that this water source is "outside" of the hydrological cycle modelled by LISFLOOD (oceans are not modelled!). Desalination plants processing water of lakes in landlocked countries are, on the contrary, retrieving water from the hydrological cycle modelled by LISFLOOD: to be consistent with the model implementation, the latter quantity did not contribute to the computation of $fractionofnonconventional$ water use, but were added to the abstraction from surface water bodies. -Clearly, leveraging on country level information leads to changes along the country borders which are generally not consistent with the physical groundwater and surface water basins. Where possible, it is recommmeded to use information at the basin or water region scale. +Clearly, leveraging on country level information leads to changes along the country borders which are generally not consistent with the physical groundwater and surface water basins. Where possible, it is recommended to use information at the basin or water region scale. ### Fraction of consumptive water use The fraction of consumptive water use defines the portion of water abstraction which is consumed and leaves the hydrological cycle. It applies to domestic, livestock, energy (cooling), and industrial uses; each fraction can be set independently as a constant for the entire modelling domain (by introducing the desired values in the OS LISFLOOD settings file) or as a map including more granular information, ideally segregated according to water regions. -Fractions of consumptive water use maps are currently not available for the European 1arcmin and global 3arcmin domains. Constant value were retrieved from the report of [Bisselink et al, 2018](https://publications.jrc.ec.europa.eu/repository/handle/JRC110927): 0.2 domestic consumptive use, 0.15 livestock consumptive use, 0.17 energy consumptive use, 0.15 industrial consumptive use. +Fractions of consumptive water use maps are currently not available for the European 1 arcmin and global 3 arcmin domains. Constant value were retrieved from the report of [Bisselink et al, 2018](https://publications.jrc.ec.europa.eu/repository/handle/JRC110927): 0.2 domestic consumptive use, 0.15 livestock consumptive use, 0.17 energy consumptive use, 0.15 industrial consumptive use. ### Irrigation efficiency, irrigation conveyance efficiency, irrigation multiplier -Water demand for irrigation is computed internally by the code according to soil mosture decific and crop type. +Water demand for irrigation is computed internally by the code according to soil moisture deficit and crop type. Irrigation efficiency, irrigation conveyance efficiency, irrigation multiplier are used to adjust the water demand to compute the volume to be abstracted for irrigation. This value, included between 0 and 1, can be a constant over the entire modelling domain (by introducing the desired values in the OS LISFLOOD settings file) or a map. -The European 1arcmin domain makes use of a map with data at the level of NUTS2 regions and information retreived from [De Roo et al, 2020](https://publications.jrc.ec.europa.eu/repository/handle/JRC120388) (Figure 3, Benitez et al, 2018). -The global 3arcmin domain currently makes use of 0.75 constant value, as indicated in [Bisselink et al, 2018](https://publications.jrc.ec.europa.eu/repository/handle/JRC110927). -Conveyance efficiency depends on how water is delivered to the fields, it is always included between 0 and 1, the lower the value, the larger the water abstraction for irrigation. It can be a constant value or a map. European 1 arcmin and global 3arcmin domains curretly use 0.8 constant value, as indicated in [Bisselink et al, 2018](https://publications.jrc.ec.europa.eu/repository/handle/JRC110927). -Irrigation multiplier is a factor larger than 1 applied to increase water demand for irrigation, to mimic the additioanl water abstraction required to prevent soil salinitization. The currently implemented value is 1.2. +The European 1 arcmin domain makes use of a map with data at the level of NUTS2 regions and information retrieved from [De Roo et al, 2020](https://publications.jrc.ec.europa.eu/repository/handle/JRC120388) (Figure 3, Benitez et al, 2018). +The global 3 arcmin domain currently makes use of 0.75 constant value, as indicated in [Bisselink et al, 2018](https://publications.jrc.ec.europa.eu/repository/handle/JRC110927). +Conveyance efficiency depends on how water is delivered to the fields, it is always included between 0 and 1, the lower the value, the larger the water abstraction for irrigation. It can be a constant value or a map. European 1 arcmin and global 3arcmin domains currently use 0.8 constant value, as indicated in [Bisselink et al, 2018](https://publications.jrc.ec.europa.eu/repository/handle/JRC110927). +Irrigation multiplier is a factor larger than 1 applied to increase water demand for irrigation, to mimic the additional water abstraction required to prevent soil salinitization. The currently implemented value is 1.2. ### Domestic leakage fraction and domestic water saving fraction -Domestic leakage fraction is used to account for the leakages from pipes in urban water supply systems: this value must be lower than 1, 0 indicates absence of leakages. Within the code, domestic leakage fraction values larger than 0 are used to compute a multiplier (>1) of water demand for domestic use to compute water abstraction for domestic use. +Domestic leakage fraction is used to account for the leakages from pipes in urban water supply systems: this value must be lower than 1 and 0 indicates absence of leakages. Within the code, domestic leakage fraction values larger than 0 are used to compute a multiplier (>1) of water demand for domestic use to compute water abstraction for domestic use. Conversely, domestic water saving fraction reduces water demand, and, consequently, water abstraction. For both inputs, OS LISFLOOD accepts a constant value or a map. The reports [Bisselink et al, 2018](https://publications.jrc.ec.europa.eu/repository/handle/JRC110927) and [De Roo et al, 2020](https://publications.jrc.ec.europa.eu/repository/handle/JRC120388) provide information on domestic leakage and water saving fraction, respectively. -In the current European 1arcmin and global 3arcmin set-ups,domestic leakage fraction is set to 0: water demnad maps are computed leveraging on water withdrawal values reported by FAO AQUASTAT[https://www.fao.org/aquastat/en/], which should, by definition, already account for leakages. +In the current European 1 arcmin and global 3 arcmin set-ups,domestic leakage fraction is set to 0: water demand maps are computed leveraging on water withdrawal values reported by FAO AQUASTAT[https://www.fao.org/aquastat/en/], which should, by definition, already account for leakages. ### Environmental flow Environmental flow is defined as the amount of water which should be always present in a river to ensure the survival (or well-being) of the aquatic ecosystem. In OS LISFLOOD, Environmental Flow is a lower threshold: water abstraction for the channel stops when discharge is lower than such a threshold. @@ -112,13 +110,12 @@ It is here noted that OS LISFLOOD equally ensures a minimum water volume in lake ### Water regions map As the spatial resolution of the model increases, the assumption of coincidence between demand and abstraction locations within the same model grid cell becomes increasingly invalid. To address this limitation, the concept of water regions is introduced. A water region is defined as a subcatchment where demand and abstraction activities occur, allowing for a more accurate representation of the spatial relationships between these processes. -*Water regions* are generally defined by sub-river-basins within a Country. In order to mimick reality, it is advisable to avoid cross-Country-border abstractions. Whenever information is available, it is strongly recommended to align the *water regions* with the actual areas managed by water management authorities, such as regional water boards. In Europe, the River Basin Districts, as defined in the Water Framework Directive and subdivided by country, can be used. +*Water regions* are generally defined by sub-river-basins within a Country. In order to mimic reality, it is advisable to avoid cross-Country-border abstractions. Whenever information is available, it is strongly recommended to align the *water regions* with the actual areas managed by water management authorities, such as regional water boards. In Europe, the River Basin Districts, as defined in the Water Framework Directive and subdivided by country, can be used. #### Consistency between water region map and model calibration protocol +Water resources (surface water bodies and groundwater) are shared inside the water region in order to meet the cumulative requirements of the entire water region area. For this reason, it is strongly recommended to include the entire water region(s) in the modelled area. If a portion of the water region is not included in the modelled area, then LISFLOOD cannot adequately compute the water demand and abstraction (it is important to notice that LISFLOOD will not crash but the results will be affected by this discrepancy). -Water resourses (surface water bodies and groundwater) are shared inside the water region in order to meet the cumulative requirements of the entire water region area. For this reason, it is strongly recommended to include the entire water region(s) in the modelled area. If a portion of the water region is not included in the modelled area, then LISFLOOD cannot adequately compute the water demand and abstraction (it is important to notice that LISFLOOD will not crush but the results will be affected by this discrepancy). - -**The inclusion of the complete water region in the computational domain becomes compulsory when performing catchment-based calibration, where parameters are optimized separately for each catchment inside the larger computational domain**. In this case, calibrated parameters are optmised for a specific model model domain. Each calibration domain must include a finite number of water regions (and each water region must be entirely included in one catchment). If and only if this condition is not met, the calibrated parameters can be correctly optimised. Conversely, when a water region belongs to one or more calibration catchments, the water resources are allocated and abstracted in different quantities during calibration as opposed to the modelling of the entire basin. +**The inclusion of the complete water region in the computational domain becomes compulsory when performing catchment-based calibration, where parameters are optimized separately for each catchment inside the larger computational domain**. In this case, calibrated parameters are optimised for a specific model domain. Each calibration domain must include a finite number of water regions (and each water region must be entirely included in one catchment). If and only if this condition is met, the calibrated parameters can be correctly optimised. Conversely, when a water region belongs to one or more calibration catchments, the water resources are allocated and abstracted in different quantities during calibration as opposed to the modelling of the entire basin. The utility [waterregions](https://github.com/ec-jrc/lisflood-utilities) can be used to 1) verify the consistency between calibration catchments and water regions or 2) create a water region map which is consistent with a set of calibration points. diff --git a/docs/5_annex_input-maps-standard-modules/index.md b/docs/5_annex_input-maps-standard-modules/index.md index 8b3d6323..ae5c8645 100644 --- a/docs/5_annex_input-maps-standard-modules/index.md +++ b/docs/5_annex_input-maps-standard-modules/index.md @@ -2,7 +2,7 @@ LISFLOOD requires input files in map or text format (the latter are called *tables*). The detailed description is provided in [this chapter](../4_Static-Maps-introduction) of LISFLOOD User Guide. -This Annex reiterates the guidelines for the prearation of meteorological varaibles and provides the list of LISFLOOD input maps required when only the standard modules are used. +This Annex reiterates the guidelines for the preparation of meteorological variables and provides the list of LISFLOOD input maps required when only the standard modules are used. The description of the optional modules in the [OS LISFLOOD Model Documentation](https://ec-jrc.github.io/lisflood-model/) includes also the list of additional maps and tables. @@ -114,7 +114,7 @@ $ET0$, $EW0$ and $ES0$ can be calculated using standard meteorological observati -***Table:*** Maps that define grid size, always required when uisng geographic (lat/lon) coordinate system.* +***Table:*** Maps that define grid size, always required when using geographic (lat/lon) coordinate system.* | Map | Default name | Units, range | Description | | --------------- | ------------ | ------------------------ | --------------------- | diff --git a/docs/5_annex_output-files/index.md b/docs/5_annex_output-files/index.md index b12ced0d..a03575f9 100644 --- a/docs/5_annex_output-files/index.md +++ b/docs/5_annex_output-files/index.md @@ -42,9 +42,9 @@ Output time series can be classified in the following categories: | depth of water on soil surface | $mm$ | WaterDepthAvUpsTS | wdepthUps.tss | | depth of snow cover on | $mm$ | SnowCoverAvUpsTS | snowCoverUps.tss | | depth of interception storage | $mm$ | CumInterceptionAvUpsTS | cumInterceptionUps.tss | -| soil moisture upper layer | $\frac{mm^3}{mm^3}$ | Theta1AvUpsTS | th1aAvUps.tss | -| soil moisture lower layer | $\frac{mm^3}{mm^3}$ | Theta2AvUpsTS | th1bAvUps.tss | -| soil moisture layer 2 | $\frac{mm^3}{mm^3}$ | Theta3AvUpsTS | th2AvUps.tss | +| soil moisture superficial layer | $\frac{mm^3}{mm^3}$ | Theta1AvUpsTS | th1AvUps.tss | +| soil moisture upper layer | $\frac{mm^3}{mm^3}$ | Theta2AvUpsTS | th2AvUps.tss | +| soil moisture lower layer | $\frac{mm^3}{mm^3}$ | Theta3AvUpsTS | th3AvUps.tss | | groundwater upper zone | $mm$ | UZAvUpsTS | uzUps.tss | | groundwater lower zone | $mm$ | LZAvUpsTS | lzUps.tss | | number of days since last rain | $days$ | DSLRAvUpsTS | dslrUps.tss | @@ -71,9 +71,9 @@ Output time series can be classified in the following categories: | **STATE VARIABLES AT SITES** (option *repStateSites*) | | | | | depth of snow cover on soil surface (pixel-average) | $mm$ | SnowCoverTS | snowCover.tss | | depth of interception storage | $mm$ | CumInterceptionTS | cumInt.tss | -| soil moisture content superficial layer | $\frac{mm^3}{mm^3}$ | Theta1TS | th1a.tss | -| soil moisture content upper layer | $\frac{mm^3}{mm^3}$ | Theta2TS | th1b.tss | -| soil moisture layer bottom layer | $\frac{mm^3}{mm^3}$ | Theta3TS | th2.tss | +| soil moisture content superficial layer | $\frac{mm^3}{mm^3}$ | Theta1TS | th1.tss | +| soil moisture content upper layer | $\frac{mm^3}{mm^3}$ | Theta2TS | th2.tss | +| soil moisture layer lower layer | $\frac{mm^3}{mm^3}$ | Theta3TS | th3.tss | | storage in upper groundwater zone | $mm$ | UZTS | uz.tss | | storage in lower groundwater zone | $mm$ | LZTS | lz.tss | | number of days since last rain | $days$ | DSLRTS | dslr.tss | @@ -121,7 +121,7 @@ In addition, some additional maps and time series may be reported for debugging | ------------------------------------------------------------ | ------------------- | ----------------- | ------------------------------------ | | **AVERAGE RECHARGE MAP (for lower groundwater zone and channel discharge)** (option *InitLisflood*) | | | | | average inflow to lower zone | $mm$ | lzavin.nc | whole pixel | -| average channel discharge (if option 'SplitRouting' = 1) | $\frac{m}{s}$ | avgdis.nc| channel | +| average channel discharge (if option 'SplitRouting' = 1) | $\frac{m^3}{s}$ | avgdis.nc| channel | LISFLOOD can also generate output end-files to allow the initialization of the soil moisture of the three soil layers and the water content of the upper groundwater zone, as well as maps of the average seppage flow from the second to the third soil layer. More details are provided in the chapter dedicated to [model initialization](../3_step4_model-initialisation). To speed up the pre-run and to prevent that results are taken from the pre-run, not necessary outputs are disabled if option 'InitLisflood' = 1 is chosen. @@ -138,7 +138,7 @@ To speed up the pre-run and to prevent that results are taken from the pre-run, | potential reference evapotranspiration | repETRefMaps | $mm$ | ETRefMaps | et | | potential evaporation from soil | repESRefMaps | $mm$ | ESRefMaps | es | | potential open water evaporation | repEWRefMaps | $mm$ | EWRefMaps | ew | -| average daily temperature | repTavgMaps | $mm$ | TavgMaps | tav | +| average daily temperature | repTavgMaps | $°C$ | TavgMaps | tav | | **VOLUME VARIABLES** | | | | | | depth of water on soil surface (overland flow) | repWaterDepthMaps | $mm$ | WaterDepthMaps | wdep | | depth of snow cover on soil surface | repSnowCoverMaps | $mm$ | SnowCoverMaps | scov | @@ -160,8 +160,8 @@ To speed up the pre-run and to prevent that results are taken from the pre-run, | leaf drainage | repLeafDrainageMaps | $\frac{mm}{timestep}$ | LeafDrainageMaps
LeafDrainageForestMaps | ldra
draF | | infiltration | repInfiltrationMaps | $\frac{mm}{timestep}$ | InfiltrationMaps
InfiltrationForestMaps | inf
infF | | preferential (bypass) flow | repPrefFlowMaps | $\frac{mm}{timestep}$ | PrefFlowMaps
PrefFlowtherMaps
PrefFlowForestMaps
PrefFlowIrrigationMaps | pflowpixel
pflow
pflowF
pflowi | -| percolation upper to lower soil layer | repPercolationMaps | $\frac{mm}{timestep}$ | Percolation1ato1bOtherMaps
Percolation1ato1bForestMaps
Percolation1ato1bIrrigationMaps
Percolation1bto2OtherMaps
Percolation1bto2ForestMaps
Percolation1bto2IrrigationMaps | Percolation1ato1bOther
Percolation1ato1bForest
Percolation1ato1bIrrigation
Percolation1bto2Other
Percolation1bto2Forest
Percolation1bto2Irrigation | -| percolation lower soil layer to subsoil | repSeepSubToGWMaps | $\frac{mm}{timestep}$ | SeepSubToGWMaps
SeepSubToGWotherMaps
SeepSubToGWforestMaps
SeepSubToGWoirrigationMaps | sgwPixel
sgwOther
sgwForest
sgwIrrigation | +| percolation upper to lower soil layer | repPercolationMaps | $\frac{mm}{timestep}$ | Percolation1ato1bOtherMaps
Percolation1to1bForestMaps
Percolation1ato1bIrrigationMaps
Percolation1bto2OtherMaps
Percolation1bto2ForestMaps
Percolation1bto2IrrigationMaps | Percolation1ato1bOther
Percolation1ato1bForest
Percolation1to2Irrigation
Percolation1bto2Other
Percolation1bto2Forest
Percolation1bto2Irrigation | +| percolation lower soil layer to subsoil | repSeepSubToGWMaps | $\frac{mm}{timestep}$ | SeepSubToGWMaps
SeepSubToGWotherMaps
SeepSubToGWforestMaps
SeepSubToGWirrigationMaps | sgwPixel
sgwOther
sgwForest
sgwIrrigation | | surface runoff | repSurfaceRunoffMaps | $\frac{mm}{timestep}$ | SurfaceRunoffMaps | srun | | outflow from upper zone | repUZOutflowMaps | $\frac{mm}{timestep}$ | UZOutflowMaps, UZOutflowForestMaps
UZOutflowIrrigationMaps | quzPixel
quz
quzF
quzi | | outflow from lower zone | repLZOutflowMaps | $\frac{mm}{timestep}$ | LZOutflowMaps | qlz | @@ -170,7 +170,7 @@ To speed up the pre-run and to prevent that results are taken from the pre-run, | loss from lower zone | repGwLossMaps | $\frac{mm}{timestep}$ | GwLossMaps | loss | -*LISFLOOD state maps* are the maps can be used to define the initial conditions of another simultion (warm start). These maps are written in output when 'repStateMaps' = 1. +*LISFLOOD state maps* are the maps can be used to define the initial conditions of another simulation (warm start). These maps are written in output when 'repStateMaps' = 1. LISFLOOD writes the results for each computational time step. The complete list of state maps is available [here](../5_annex_state-variables/index.md). @@ -181,8 +181,8 @@ The users should be aware that some state maps are generated only if the relevan **Note** -Some cumulative stoarges and volumes are computed internally by LISFLOOD. Some relevant exmaple is described below: -- Total Water Storage is the total water volume stored in channels, lakes, reservoirs, snow cover, sealed surfaces depressions, surface runoff, canopy interception, uppper and lower groundwater zones. +Some cumulative storages and volumes are computed internally by LISFLOOD. Some relevant example is described below: +- Total Water Storage is the total water volume stored in channels, lakes, reservoirs, snow cover, sealed surfaces depressions, surface runoff, canopy interception, upper and lower groundwater zones. - Surface runoff is the sum of direct runoff (from sealed and water fractions) and runoff generated by the pervious land cover fractions (forest, irrigation, other). - Total runoff is the sum of surface runoff and sub-surface runoff. Sub-surface runoff is the outflow from upper and lower groundwater zones. diff --git a/docs/5_annex_settings_and_options/index.md b/docs/5_annex_settings_and_options/index.md index f04b4e35..18effa70 100644 --- a/docs/5_annex_settings_and_options/index.md +++ b/docs/5_annex_settings_and_options/index.md @@ -3,14 +3,14 @@ This annex presents a nearly comprehensive list of setting options, inputs, and The content is organized in the following tables: - [**lfoptions**](../5_annex_settings_and_options/index.md#table-lfoptions-section-in-os-lisflood-settings-xml): list of available switches to activate optional modules and optional outputs (time series and map formats) -- [**luser**](../5_annex_settings_and_options/index.md#table-lfuser-in-os-lisflood-settings-xml): list of variables which are generally defined by the users. -- [**lfbinding**](../5_annex_settings_and_options/index.md#table-lfbinging-section-in-os-lisflood-settings-xml): list of model variables. +- [**lfuser**](../5_annex_settings_and_options/index.md#table-lfuser-in-os-lisflood-settings-xml): list of variables which are generally defined by the users. +- [**lfbinding**](../5_annex_settings_and_options/index.md#table-lfbinding-section-in-os-lisflood-settings-xml): list of model variables. - [**initial variables**](../5_annex_settings_and_options/index.md#table-variables-required-for-model-initialization): list of variables required for model initialization. The table indicates values/maps required by the cold and warm start of both prerun and run) ## **Table:** *lfoptions section in OS LISFLOOD settings xml* -The table below presents the ist of available switches to activate optional modules and optional outputs (time series and map formats). For each option, 1 = ON; 0 = OFF. Deault staus is 0 = OFF, unless otherwise indicated in the table. +The table below presents the list of available switches to activate optional modules and optional outputs (time series and map formats). For each option, 1 = ON; 0 = OFF. Default status is 0 = OFF, unless otherwise indicated in the table. | module | KEY | Type | I/O | Description | |:-------------------------------------------|:----------------------------------------|:--------------------------------------|:-------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -288,8 +288,8 @@ The table below presents the ist of available switches to activate optional modu | ROUTING | ChannelsMCT | map | input | Boolean map with value 1 at channel pixels where MCT is used, and 0 at all other pixels | | REPORTED OUTPUT MAPS (END) | ChanQAvgDtEnd | map | output/end | Reported average discharge on the last routing sub-step [cu m/s] ChanQAvgDt | | REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | ChanQAvgDtState | map | output/state | Reported average discharge the last routing sub-step [cu m/s] ChanQAvgDt | -| REPORTED OUTPUT MAPS (END) | ChanQEnd | map | output/end | Reported istantaneous discharge at end of computation step [cu m/s] ChanQ | -| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | ChanQState | map | output/state | Reported istantaneous discharge at end of computation step [cu m/s] ChanQ | +| REPORTED OUTPUT MAPS (END) | ChanQEnd | map | output/end | Reported instantaneous discharge at end of computation step [cu m/s] ChanQ | +| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | ChanQState | map | output/state | Reported instantaneous discharge at end of computation step [cu m/s] ChanQ | | REPORTED OUTPUT MAPS (END) | ChSideEnd | map | output/end | Reported channel side flow | | REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | ChSideState | map | output/state | Reported sideflow to channel for first line of routing [m3/s] | | WATER USE MAPS AND PAR | ConveyanceEfficiency | map | input | onveyance efficiency, around 0.80 for average channel | @@ -433,35 +433,35 @@ The table below presents the ist of available switches to activate optional modu | SNOW AND FROST | TemperatureLapseRate | value | input | Temperature lapse rate with altitude [deg C / m] It is the temperature lapse rate that is used to estimate average temperature at the centroid of each pixel’s elevation zones [°C m-1] | | SNOW AND FROST | TempMelt | value | input | It is the degree-day factor that controls the rate of snowmelt [mm °C-1 day-1] | | SNOW AND FROST | TempSnow | value | input | It is the average temperature below which precipitation is assumed to be snow [°C] | -| REPORTED OUTPUT MAPS (END) | Theta1End | map | output/end | Reported volumetric soil moisture content for soil layer 1a [V/V] | -| REPORTED OUTPUT MAPS (END) | Theta1ForestEnd | map | output/end | Reported volumetric soil moisture content for soil layer 1a for forest [V/V] | -| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta1ForestState | map | output/state | theta for soil layer 1a forest fraction | -| REPORTED OUTPUT MAPS (END) | Theta1IrrigationEnd | map | output/end | Reported volumetric soil moisture content for soil layer 1a [V/V] | -| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta1IrrigationState | map | output/state | Reported volumetric soil moisture content for soil layer 1a for irrigation[V/V] | +| REPORTED OUTPUT MAPS (END) | Theta1End | map | output/end | Reported volumetric soil moisture content for soil layer 1 [V/V] | +| REPORTED OUTPUT MAPS (END) | Theta1ForestEnd | map | output/end | Reported volumetric soil moisture content for soil layer 1 for forest [V/V] | +| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta1ForestState | map | output/state | theta for soil layer 1 forest fraction | +| REPORTED OUTPUT MAPS (END) | Theta1IrrigationEnd | map | output/end | Reported volumetric soil moisture content for soil layer 1 [V/V] | +| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta1IrrigationState | map | output/state | Reported volumetric soil moisture content for soil layer 1 for irrigation[V/V] | | REPORTED OUTPUT MAPS (INDIVIDUAL STATE VAR AT EVERY TIME STEP) | Theta1Maps | map | output | Reported volumetric soil moisture content for soil layer 1 [V/V] | | REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta1State | map | output/state | Reported volumetric soil moisture content for soil layer 1 [V/V] | -| REPORTED OUTPUT MAPS (END) | Theta2End | map | output/end | Reported volumetric soil moisture content for both soil layer 1b [V/V] | -| REPORTED OUTPUT MAPS (END) | Theta2ForestEnd | map | output/end | Reported volumetric soil moisture content for both soil layer 1b for forest [V/V] | -| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta2ForestState | map | output/state | theta for soil layer 1b forest fraction | -| REPORTED OUTPUT MAPS (END) | Theta2IrrigationEnd | map | output/end | Reported volumetric soil moisture content for soil layer 1b [V/V] | -| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta2IrrigationState | map | output/state | Reported volumetric soil moisture content for both soil layer 1b for irrigation [V/V] | +| REPORTED OUTPUT MAPS (END) | Theta2End | map | output/end | Reported volumetric soil moisture content for both soil layer 2 [V/V] | +| REPORTED OUTPUT MAPS (END) | Theta2ForestEnd | map | output/end | Reported volumetric soil moisture content for both soil layer 2 for forest [V/V] | +| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta2ForestState | map | output/state | theta for soil layer 2 forest fraction | +| REPORTED OUTPUT MAPS (END) | Theta2IrrigationEnd | map | output/end | Reported volumetric soil moisture content for soil layer 2 [V/V] | +| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta2IrrigationState | map | output/state | Reported volumetric soil moisture content for both soil layer 2 for irrigation [V/V] | | REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta2State | map | output/state | Reported volumetric soil moisture content for both soil layer 2 [V/V] | -| REPORTED OUTPUT MAPS (END) | Theta3End | map | output/end | Reported volumetric soil moisture content for both soil layer 2 [V/V] | -| REPORTED OUTPUT MAPS (END) | Theta3ForestEnd | map | output/end | Reported volumetric soil moisture content for both soil layer 2 [V/V] | -| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta3ForestState | map | output/state | theta for soil layer 2 forest fraction | -| REPORTED OUTPUT MAPS (END) | Theta3IrrigationEnd | map | output/end | Reported volumetric soil moisture content for soil layer 2 [V/V] | -| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta3IrrigationState | map | output/state | Reported volumetric soil moisture content for both soil layer 2 for irrigation [V/V] | -| REPORTED OUTPUT MAPS (INDIVIDUAL STATE VAR AT EVERY TIME STEP) | Theta3Maps | map | output | Reported volumetric soil moisture content for soil layer 2 [V/V] | +| REPORTED OUTPUT MAPS (END) | Theta3End | map | output/end | Reported volumetric soil moisture content for both soil layer 3 [V/V] | +| REPORTED OUTPUT MAPS (END) | Theta3ForestEnd | map | output/end | Reported volumetric soil moisture content for both soil layer 3 [V/V] | +| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta3ForestState | map | output/state | theta for soil layer 3 forest fraction | +| REPORTED OUTPUT MAPS (END) | Theta3IrrigationEnd | map | output/end | Reported volumetric soil moisture content for soil layer 3 [V/V] | +| REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta3IrrigationState | map | output/state | Reported volumetric soil moisture content for both soil layer 3 for irrigation [V/V] | +| REPORTED OUTPUT MAPS (INDIVIDUAL STATE VAR AT EVERY TIME STEP) | Theta3Maps | map | output | Reported volumetric soil moisture content for soil layer 3 [V/V] | | REPORTED OUTPUT MAPS (STATE VARIABLES AT SELECTED TIME STEPS) | Theta3State | map | output/state | Reported volumetric soil moisture content for both soil layer 3 [V/V] | -| INITIAL CONDITION | ThetaForestInit1Value | value/map | input initial/internal | initial soil moisture content layer 1a -9999: use field capacity values | -| INITIAL CONDITION | ThetaForestInit2Value | value/map | input initial/internal | initial soil moisture content layer 1b -9999: use field capacity values | -| INITIAL CONDITION | ThetaForestInit3Value | value/map | input initial/internal | initial soil moisture content layer 2 -9999: use field capacity values | -| INITIAL CONDITION | ThetaInit1Value | value/map | input initial/internal | initial soil moisture content layer 1a -9999: use field capacity values | -| INITIAL CONDITION | ThetaInit2Value | value/map | input initial/internal | initial soil moisture content layer 1b -9999: use field capacity values | -| INITIAL CONDITION | ThetaInit3Value | value/map | input initial/internal | initial soil moisture content layer 2 -9999: use field capacity values | -| INITIAL CONDITION | ThetaIrrigationInit1Value | value/map | input initial/internal | initial soil moisture content layer 1a for irrigation -9999: use field capacity values | -| INITIAL CONDITION | ThetaIrrigationInit2Value | value/map | input initial/internal | initial soil moisture content layer 1b for irrigation -9999: use field capacity values | -| INITIAL CONDITION | ThetaIrrigationInit3Value | value/map | input initial/internal | initial soil moisture content layer 2 for irrigation -9999: use field capacity values | +| INITIAL CONDITION | ThetaForestInit1Value | value/map | input initial/internal | initial soil moisture content layer 1 -9999: use field capacity values | +| INITIAL CONDITION | ThetaForestInit2Value | value/map | input initial/internal | initial soil moisture content layer 2 -9999: use field capacity values | +| INITIAL CONDITION | ThetaForestInit3Value | value/map | input initial/internal | initial soil moisture content layer 3 -9999: use field capacity values | +| INITIAL CONDITION | ThetaInit1Value | value/map | input initial/internal | initial soil moisture content layer 1 -9999: use field capacity values | +| INITIAL CONDITION | ThetaInit2Value | value/map | input initial/internal | initial soil moisture content layer 2 -9999: use field capacity values | +| INITIAL CONDITION | ThetaInit3Value | value/map | input initial/internal | initial soil moisture content layer 3 -9999: use field capacity values | +| INITIAL CONDITION | ThetaIrrigationInit1Value | value/map | input initial/internal | initial soil moisture content layer 1 for irrigation -9999: use field capacity values | +| INITIAL CONDITION | ThetaIrrigationInit2Value | value/map | input initial/internal | initial soil moisture content layer 2 for irrigation -9999: use field capacity values | +| INITIAL CONDITION | ThetaIrrigationInit3Value | value/map | input initial/internal | initial soil moisture content layer 3 for irrigation -9999: use field capacity values | | INITIAL CONDITION | timestepInit | value/date | input initial/internal | If initial conditions are stored as netCDF stack, this variable sets which time step to use as initial step. It can be either a date (e.g. 1/1/2010) or a number (e.g. 5). If a number is used, it refers to "CalendarDayStart". (it is generally one step back compared to StepStart) If missing, netcdf file are read with no reference to 'time', either if they are a stack or not. timestepInit is ignored if netCDF file is a single netCDF file.. | | REPORTED OUTPUT MAPS | TopSoilMoistureMaps | map (missing) | output | Reported Topsoil moisture [%] | | INITIAL CONDITION | TotalCrossSectionAreaInitValue | value/map | input initial/internal | initial cross-sectional area of flow in channel[m2] -9999: use half bankfull | diff --git a/docs/5_annex_state-variables/index.md b/docs/5_annex_state-variables/index.md index 4e112051..534b2e0e 100644 --- a/docs/5_annex_state-variables/index.md +++ b/docs/5_annex_state-variables/index.md @@ -17,21 +17,21 @@ | CumInterceptionForestState | cumf | CumInterception[1] | mm | Reported interception storage for forest | | CumInterceptionIrrigationState | cumi | CumInterception[2] | mm | Reported interception storage for irrigation | | CumIntSealedState | cseal | CumInterSealed | mm | Reported cumulative depressions storage | -| Theta1State | tha | Theta1a[0] | - | Reported volumetric soil water content for superficial soil layer (1a), other fraction [V/V] | -| Theta1ForestState | thfa | Theta1a[1] | - | Reported volumetric soil water content for superficial soil layer (1a), forest fraction [V/V] | -| Theta1IrrigationState | thia | Theta1a[2] | - | Reported volumetric soil water content for superficial soil layer (1a), irrigation fraction [V/V] | -| Theta2State | thb | Theta1b[0] | - | Reported volumetric soil water content for upper soil layer (1b), other fraction [V/V] | -| Theta2ForestState | thfb | Theta1b[1] | - | Reported volumetric soil water content for upper soil layer (1b), forest fraction [V/V] | -| Theta2IrrigationState | thib | Theta1b[2] | - | Reported volumetric soil water content upper soil layer (1b), irrigation fraction [V/V] | -| Theta3State | thc | Theta2[0] | - | Reported volumetric soil water content for lower soil layer (2), other fraction [V/V] | -| Theta3ForestState | thfc | Theta2[1] | - | Reported volumetric soil water content for lower soil layer (2), forest fraction [V/V] | -| Theta3IrrigationState | thic | Theta2[2] | - | Reported volumetric soil water content for for lower soil layer (2), irrigation fraction [V/V] | +| Theta1State | th1 | Theta1a[0] | - | Reported volumetric soil water content for superficial soil layer (1), other fraction [V/V] | +| Theta1ForestState | thf1 | Theta1a[1] | - | Reported volumetric soil water content for superficial soil layer (1), forest fraction [V/V] | +| Theta1IrrigationState | thi1 | Theta1a[2] | - | Reported volumetric soil water content for superficial soil layer (1), irrigation fraction [V/V] | +| Theta2State | th2 | Theta1b[0] | - | Reported volumetric soil water content for upper soil layer (2), other fraction [V/V] | +| Theta2ForestState | thf2 | Theta1b[1] | - | Reported volumetric soil water content for upper soil layer (2), forest fraction [V/V] | +| Theta2IrrigationState | thi2 | Theta1b[2] | - | Reported volumetric soil water content upper soil layer (2), irrigation fraction [V/V] | +| Theta3State | th3 | Theta2[0] | - | Reported volumetric soil water content for lower soil layer (3), other fraction [V/V] | +| Theta3ForestState | thf3 | Theta2[1] | - | Reported volumetric soil water content for lower soil layer (3), forest fraction [V/V] | +| Theta3IrrigationState | thi3 | Theta2[2] | - | Reported volumetric soil water content for for lower soil layer (3), irrigation fraction [V/V] | | UZState | uz | UZ[0] | mm | Reported storage in upper groundwater zone, other fraction | | UZForestState | uzf | UZ[1] | mm | Reported storage in upper groundwater zone, forest fraction | | UZIrrigationState | uzi | UZ[2] | mm | Reported storage in upper groundwater zone, irrigation fraction | | LZState | lz | LZ | mm | Reported storage in lower groundwater zone | -| ChanQState | chanq | ChanQ | m3/s | Reported istantaneous discarge at end of the model time step | -| ChanQAvgDtState *L | chanqavgdt | ChanQAvgDt | m3/s | Reported average discarge for the last routing sub-step | +| ChanQState | chanq | ChanQ | m3/s | Reported instantaneous discharge at end of the model time step | +| ChanQAvgDtState *L | chanqavgdt | ChanQAvgDt | m3/s | Reported average discharge for the last routing sub-step | | LakeLevelState *L | lakeh | LakeLevel | m | Output map(s) with lake level | | LakePrevInflowState *L | lakeprevinq | LakeInflowOld | m3/s | Output map with lake average inflow at previous routing sub-step (ChanQ(t-1)) | | LakePrevOutflowState *L | lakeprevoutq | LakeOutflow | m3/s | Output map with lake average outflow at previous routing sub-step (ChanQ(t-1)) | diff --git a/docs/5_annex_tests/index.md b/docs/5_annex_tests/index.md index e8c0cbcc..fe439af6 100644 --- a/docs/5_annex_tests/index.md +++ b/docs/5_annex_tests/index.md @@ -42,8 +42,8 @@ Tests that are using Comparator classes are: | test_init_6h | test_results.py | NetCDFComparator(atol=0.0001, rtol=0.001), TSSComparator(atol=0.0001, rtol=0.001) | | test_warmstart_daily | test_warmstart.py | NetCDFComparator(atol=0.0001, rtol=0.001), TSSComparator(array_equal=True) | | test_warmstart_6h | test_warmstart.py | NetCDFComparator(atol=0.0001, rtol=0.001), TSSComparator(array_equal=True) | -| test_subcacthment_daily | test_subcatchments.py | NetCDFComparator(array_equal=True) | -| test_subcacthment_6h | test_subcatchments.py | NetCDFComparator(array_equal=True) | +| test_subcatchment_daily | test_subcatchments.py | NetCDFComparator(array_equal=True) | +| test_subcatchment_6h | test_subcatchments.py | NetCDFComparator(array_equal=True) | | test_reported_steps | test_reported_steps.py | NetCDFComparator(array_equal=True) | | test_waterabstraction_24h| test_water_abstraction.py| NetCDFComparator(array_equal=True) | | test_waterabstraction_6h | test_water_abstraction.py| NetCDFComparator(array_equal=True) | @@ -647,10 +647,10 @@ This test demonstrates that wateruse module introduces incongruities between run |Test case | DtSec | Simulation period | Expected | |-------------------------------------------------------|-------|------------------------------------|--------------------------------| -| test_subcacthment_daily | 86400 |02/01/2016 06:00 - 30/03/2016 06:00 | all netcdf are array equal | -| test_subcacthment_6h | 21600 |01/03/2016 06:00 - 30/03/2016 06:00 | all netcdf are array equal | -| test_subcacthment_daily_wateruse_groundwatersmooth_OFF| 86400 |02/01/2016 06:00 - 30/01/2016 06:00 | all netcdf are array equal | -| test_subcacthment_daily_wateruse_groundwatersmooth_ON | 86400 |02/01/2016 06:00 - 30/01/2016 06:00 | the results are not identical | +| test_subcatchment_daily | 86400 |02/01/2016 06:00 - 30/03/2016 06:00 | all netcdf are array equal | +| test_subcatchment_6h | 21600 |01/03/2016 06:00 - 30/03/2016 06:00 | all netcdf are array equal | +| test_subcatchment_daily_wateruse_groundwatersmooth_OFF| 86400 |02/01/2016 06:00 - 30/01/2016 06:00 | all netcdf are array equal | +| test_subcatchment_daily_wateruse_groundwatersmooth_ON | 86400 |02/01/2016 06:00 - 30/01/2016 06:00 | the results are not identical | **Note:** This test doesn't use a reference dataset so it's not a black-box test. It ensures that simulations on domain and its subdomains are equivalent. @@ -672,14 +672,14 @@ modules_to_unsetGW= [ 'groundwaterSmooth', ] -def test_subcacthment_daily(self): +def test_subcatchment_daily(self): step_start = '02/01/2016 06:00' step_end = '30/03/2016 06:00' dt_sec = 86400 report_steps = '3650..4100' self.run_subcathmenttest_by_dtsec(dt_sec, step_end, step_start, report_steps=report_steps) -def test_subcacthment_daily_wateruse_groundwatersmooth_ON(self): +def test_subcatchment_daily_wateruse_groundwatersmooth_ON(self): step_start = '02/01/2016 06:00' step_end = '30/01/2016 06:00' dt_sec = 86400 diff --git a/docs/index.md b/docs/index.md index 8e8daa41..0fd2b981 100644 --- a/docs/index.md +++ b/docs/index.md @@ -10,7 +10,7 @@ He was a scientist and educator to his core. During an exceptional career, he pu Ad’s ability to push the boundaries of science and to see the applications of said science has been at the heart of the LISFLOOD model that serves hydrologists and the wider academic community worldwide for their research. LISFLOOD is also the core of the European and Global Flood Awareness Systems. Whilst these started as research projects under his leadership and guidance, they have become cornerstones of the operational Copernicus Emergency Management service. As such, Ad’s science regularly serves to improve Europeans abilities to tackle flood related disasters. Ad provided a safe space for his students and early-career colleagues, helping them to flourish and make the best of their skills for our institution. He provided scientific advice to peers, and was always a highly professional, dependable, reliable and much valued colleague. -Enyone who's ever met Ad remembers him with a smile, with kind words and easy going attitude. We pledge to continue working on his Lisflood legacy.
+Everyone who's ever met Ad remembers him with a smile, with kind words and easy going attitude. We pledge to continue working on his Lisflood legacy.
------------------------------------ LISFLOOD User Guide