Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions Regarding Settings File Configuration #158

Open
Nooshdokht-Bayatafshary opened this issue May 25, 2024 · 5 comments
Open

Questions Regarding Settings File Configuration #158

Nooshdokht-Bayatafshary opened this issue May 25, 2024 · 5 comments

Comments

@Nooshdokht-Bayatafshary
Copy link

Nooshdokht-Bayatafshary commented May 25, 2024

Dear developers,

I am currently working on setting options in the LISFLOOD settings XML file for calibrating my region. I've encountered a few queries:

  1. I'm unsure about the precise moment to activate the indicator key. Could you provide clarification regarding its function and the recommendation for activation?

  2. It appears that the openwaterevapo key is activated to simulate evaporation from open water surfaces. Upon reviewing the model's source code, it seems logical to activate this key only when modeling lakes. Could you confirm this assumption? Additionally, if the assumption holds true, I'm curious about the methodology for calculating evaporation from reservoir water bodies in areas lacking natural lakes. We've generated a fracwater file within the land use section—does this file encompass the necessary calculations for water evaporation?

  3. Concerning the GroundwaterBodies key, does it pertain to delineating the aquifer zones within the area? In cases where multiple aquifers exist (two or three), should each be represented by a '1' in the respective file?

Thank you for your assistance in clarifying these points.

Best regards,
Nooshdokht

@StefaniaGrimaldi
Copy link
Contributor

StefaniaGrimaldi commented May 26, 2024

Dear @Nooshdokht-Bayatafshary ,

thank you for your enquiry. Please find our answers below:

  1. The “indicator” option allows activating the module indicatorcalc (https://github.com/ec-jrc/lisflood-code/blob/master/src/lisflood/hydrological_modules/indicatorcalc.py). This module computes a set of output variables for the analysis of water abstraction and consumption for anthropogenic use. For example, the module computes the total monthly water abstraction from lakes and reservoirs within each water use region, as well as indices such as the Falkenmark indicator (a measure of water scarcity that relates water resources to the total population in a region). Please be aware that the functioning of this module also requires a population input map. It must be noted that this module computes outputs and support relevant analysis but it does not contribute to the modelling of the hydrological processes. During calibration this module can be OFF (calibration explores the parameter space using an objective function comparing, for instance, simulated and observed discharge time series - clearly, calibration against other variables, such as soil moisture, is also possible). Once the calibrated parameters are available, setting the “indicator” option to 1 will allow the generation of the set of outputs explained above.

  2. Your understanding is correct: openwater optional module allows simulating evaporation from open water surfaces. This module requires the input map lakemask. Albeit the name only mentions lakes (and this is indeed misleading), the lakemask can include open water surfaces such as wetlands and reservoirs. The map lakemask is different from the map lakes (the map lakes only includes the location of the outlets of the lakes explicitly included in the model set-up, https://ec-jrc.github.io/lisflood-code/4_Static-Maps_reservoirs-lakes/). The map lakemask is used to identify the intersection between open water areas and the local drainage direction map: computed evaporated water is removed from the channels in https://github.com/ec-jrc/lisflood-code/blob/master/src/lisflood/hydrological_modules/routing.py#L464 . The map lakemask must be consistent with the map fracwater.

  3. The GroundwaterBodies map allows identifying pixels with exploitable groundwater resources (possible values: 1, 0). This map is relevant for the computation of water abstraction for anthropogenic use. As an example, this paper https://asr.copernicus.org/articles/17/227/2020/ explains the generation of the GroundwaterBodies map for Europe. GroundwaterBodies map is not used for the computation of water fluxes in the upper and lower groundwater zones (in https://github.com/ec-jrc/lisflood-code/blob/master/src/lisflood/hydrological_modules/groundwater.py).

We hope that the answers above help. Please do not hesitate to share your questions and remarks.

On behalf of the developers team,
kind regards,
Stefania

@Nooshdokht-Bayatafshary
Copy link
Author

Dear @StefaniaGrimaldi,

Thank you very much for your detailed explanation. Based on your explanation, could you please further clarify or confirm the following points?
Based on the manual, I understand that for a region with multiple dams but no natural lakes, I need to enable the lake module and generate the following files accordingly:

  • lakes.map: This file should represent the mask of the lake areas, which correspond to the reservoir areas of the dams.
  • lakes.nc: This file should indicate the outlet positions of the lakes, which are the same as the outlet positions of the dams (similar to the res.nc file).
  • lakearea.txt: A table specifying the areas of the dams.
  • lakea.txt: A table containing the alpha parameters.
  • lakeavinflow.txt: A table detailing the average inflows of the dams.

Considering the above, I would greatly appreciate your advice on the following points based on your expertise:

  1. For lakearea.txt, should I use the average areas of the lakes over the modeling period, or should I use the maximum areas of the dam lakes?
  2. Should the lake masks in lakes.map be based on the maximum areas of the dam lakes?
  3. When determining the alpha parameters, is it better to consider the width of the river exiting the dams, the dam gates, or the spillways?

Your guidance on these questions will be highly valuable. Thank you in advance for your assistance.

Best regards,
Nooshdokht

@StefaniaGrimaldi
Copy link
Contributor

StefaniaGrimaldi commented May 27, 2024

Dear @Nooshdokht-Bayatafshary,

thank you for your reply.

I believe that it is important to clarify that Dams and Lakes are modelled by OS LISFLOOD using two separate routines.

The reservoirs module allow the modelling of storage area generated and regulated by a human made barrier (or dam). The outflow from a reservoirs depends on operational rules. The modelling of reservoirs is explained here: https://ec-jrc.github.io/lisflood-model/3_03_optLISFLOOD_reservoirs/.

Natural lakes (no man-made barriers) are modelled using the lakes module, which is described here https://ec-jrc.github.io/lisflood-model/3_02_optLISFLOOD_lakes/. The outflow from a lake is modelled using weir equations.

The modelling of “a region with multiple dams but no natural lakes” should leverage on the reservoirs module.
Please let me know if I misunderstood the description of your study area.

The input maps and txt files listed in your message allow the modelling of lakes:

  • lakes.nc provides the location of the outlet point of each lake (https://ec-jrc.github.io/lisflood-code/4_Static-Maps_reservoirs-lakes/)
  • lakearea.txt: a table specifying the areas of the lakes. To prepare this input, it is important to consider that the computational module assumes a linear relation between area and water level (storage = area * water level)
  • lakea.txt: A table containing the alpha parameters, this can be approximated by the river width at the outlet of the lake.
  • lakeavinflow.txt: A table detailing the average inflows to each lake.

The following input maps and text files are required for the modelling of reservoirs:

  • res.nc provides the location of the outlet point of each reservoir (https://ec-jrc.github.io/lisflood-code/4_Static-Maps_reservoirs-lakes/)
  • reservoirs storage capacity;
  • reservoirs normal storage limit;
  • reservoirs flood storage limit;
  • reservoirs conservative storage limit;
  • reservoirs normal outflow;
  • reservoirs non-damaging outflow;
  • reservoirs minimum outflow.

As mentioned in the previous message, the map lakemask is used to compute evaporation from open surface bodies and it can include lakes, reservoirs, wetlands. This map is not used to compute the outflow from lakes/reservoirs, but the losses from open water areas due to evaporation. Its generation is bounded to the fracwater map. Are you planning on using static or dynamic land cover fraction maps?

You might be interested in exploring the input maps of the current global implementation of OS LISFLOOD within the Copernicus Emergency Management Service Global Flood Awareness System (https://global-flood.emergency.copernicus.eu/. All the maps are available from: https://data.jrc.ec.europa.eu/dataset/68050d73-9c06-499c-a441-dc5053cb0c86 --> https://jeodpp.jrc.ec.europa.eu/ftp/jrc-opendata/CEMS-GLOFAS/LISFLOOD_static_and_parameter_maps_for_GloFAS/README.txt and https://jeodpp.jrc.ec.europa.eu/ftp/jrc-opendata/CEMS-GLOFAS/LISFLOOD_static_and_parameter_maps_for_GloFAS/Lakes_Reservoirs_ID_tables/

Finally, this paper https://www.sciencedirect.com/science/article/pii/S0022169417301671?via%3Dihub#s0010 presents the preparation of lakes and reservoirs input data for the global set-up.

We hope that our answer helps,
kind regards,
on behalf of the developers team,
Stefania

@Nooshdokht-Bayatafshary
Copy link
Author

Dear @StefaniaGrimaldi,

Thank you for providing comprehensive insights into modeling dams and lakes using LISFLOOD. Your clarification has been immensely valuable in understanding the tailored routines for reservoirs and natural lakes.

One key misconception I had was about the capabilities of the openwater module, specifically its association with the lake and reservoirs module. I am grateful for your correction on this point.

In the area I'm focused on, there are no natural lakes but rather 8 reservoirs. Based on your guidance, it seems appropriate to activate the reservoir module while deactivating the lake module. Additionally, enabling the openwater module, which requires lakemask.nc.

Furthermore, my plans involve utilizing the TransientLandUseChange module. I've prepared land use maps for each year and have corresponding time-varying files such as fracforest, fracwater, fracother, and fracrice as per the manual's instructions. For consistency between the lakemask and the fracwater map, synchronizing the lakemask with the fracwater over time appears logical. Is this understanding accurate? Also, in this scenario, is it necessary for the varfractionwater module to be activated?

I would greatly appreciate your expertise on these matters.

Warm regards,
Nooshdokht

@StefaniaGrimaldi
Copy link
Contributor

Dear @Nooshdokht-Bayatafshary,

we are pleased to know that our answers are useful: thank you for the feedback.

Your message mentions 4 land use fractions. Generally speaking, OS LISFLOOD can account for to 6 fractions (https://ec-jrc.github.io/lisflood-code/4_Static-Maps_land-use/). If your study area does not include neither sealed surfaces nor rice irrigation, you might need to create maps with 0 value in each pixel. In each pixel, the sum of all fractions must be exactly 1.0.

Since you will be using the TransientLandUseChange module to account for the temporal variation of water fraction, a solution could consist in generating the lakemask using the maximum area (as you suggested above): evaporation from open water is then expected to be computed according to the water fraction: https://github.com/ec-jrc/lisflood-code/blob/master/src/lisflood/hydrological_modules/evapowater.py#L132C13-L132C25

Please do not hesitate to share your questions and comments,
kind regards,
on behalf of the developers team,
Stefania

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants