You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow water abstractions from lake and reservoir for example for irrigation purposes.
Without the water demands concept, wflow can allow for external water inflow/abstractions but only from the river water volume and not the reservoir. It would be good to allow for this, especially if the data is available (for example for reservoir operators).
Implementation Description
It is possible to add or remove external inflows by adding an inflow variable to the forcing file (together with precipitation, temperature and potential evapotranspiration). This variable contains 0 by default and then inflow or abstractions for the concerned grid cell locations. However, these inflow or abstractions are currently taken out of the river water volume rather than the reservoir. A minor change is then needed so that abstractions in reservoir cells are taken out from the reservoir volume rather than from the river. Alternatively, reservoir inflow could become an independent variable from the river inflow and CSV or NetCDF-CF_TIMESERIES input format for these timeseries could be considered in order to simplify processing.
To check in refinements: how abstractions from reservoirs are calculated if any when the water demands concept is on and can it work if local data is available.
Additional Context
Timely and accurate forecast is crucial to predict and respond to flood or drought risk. For reservoir operators or basins that contains reservoirs, adapting reservoir operations in time might help reduce the impact of drought or floods. During our work with Sunwater, we noticed that in forecast mode, it is important that reservoir models, here Wflow, can reflect accurately reservoir operations such as:
Modification of the release outflow and/or rating curves.
Account for varying abstractions from the reservoirs (e.g. for irrigation).
If not considered properly, there is a risk that the model starts differing from the observations, reducing the accuracy of the forecast.
This issue is part of these improvements.
The text was updated successfully, but these errors were encountered:
Feature type
Adding new functionality
Improvement Description
Allow water abstractions from lake and reservoir for example for irrigation purposes.
Without the water demands concept, wflow can allow for external water inflow/abstractions but only from the river water volume and not the reservoir. It would be good to allow for this, especially if the data is available (for example for reservoir operators).
Implementation Description
It is possible to add or remove external inflows by adding an inflow variable to the forcing file (together with precipitation, temperature and potential evapotranspiration). This variable contains 0 by default and then inflow or abstractions for the concerned grid cell locations. However, these inflow or abstractions are currently taken out of the river water volume rather than the reservoir. A minor change is then needed so that abstractions in reservoir cells are taken out from the reservoir volume rather than from the river. Alternatively, reservoir inflow could become an independent variable from the river inflow and CSV or NetCDF-CF_TIMESERIES input format for these timeseries could be considered in order to simplify processing.
To check in refinements: how abstractions from reservoirs are calculated if any when the water demands concept is on and can it work if local data is available.
Additional Context
Timely and accurate forecast is crucial to predict and respond to flood or drought risk. For reservoir operators or basins that contains reservoirs, adapting reservoir operations in time might help reduce the impact of drought or floods. During our work with Sunwater, we noticed that in forecast mode, it is important that reservoir models, here Wflow, can reflect accurately reservoir operations such as:
If not considered properly, there is a risk that the model starts differing from the observations, reducing the accuracy of the forecast.
This issue is part of these improvements.
The text was updated successfully, but these errors were encountered: