Evaluation and Restructuring of Lake and Reservoir Structs

[alimeshgi]

Feature type

Changing existing functionality

Improvement Description

The current implementation of lake and reservoir structs may contain shared functionality, leading to potential code duplication and decreased maintainability. To address this issue and improve the design of these structs, it's necessary to examine the shared functionality and explore restructuring based on user input.

Implementation Description

1)Examination of Shared Functionality:
Conduct a thorough examination of the lake and reservoir structs to identify shared functionality, such as water level management, inflow/outflow calculations, and storage capacity constraints.
Determine areas where functionality can be consolidated or abstracted to reduce redundancy and improve code maintainability.

2)User Input and Feedback:
Gather input from users and stakeholders regarding their requirements and preferences for the design of lake and reservoir structs.
Incorporate user feedback into the restructuring process to ensure that the new design aligns with the needs of the user community and addresses common use cases effectively.

3)Restructuring for Improved Design:
Explore restructuring options, such as introducing a common base struct for lakes and reservoirs or utilizing composition to encapsulate shared functionality.
Refactor the existing structs based on the identified shared functionality and user input, aiming to improve design clarity, modularity, and extensibility.

Additional Context

No response

[Starphire1]

@alimeshgi thanks for your post on lakes/reservoirs. I also would like to see more functionality with water level management and inflow/outflow calculations. Cheers.

[shartgring]

Good point @alimeshgi , happy to see it listed here

It is something I encountered when modelling the reservoirs in the Rur catchment. Currently, we implemented the reservoirs using the hq rating curves. However, this means that in practice the reservoirs are included in the model as 'lakes', as this is only supported for lakes. As a result, I need to include a very clear description of this lake-reservoir-trick when the model is shared. A shared concept for both lakes and reservoirs ("waterbody"?) may prevent such confusion/risk of miscommunication

[alimeshgi]

thanks for your feedback and nice suggestion @shartgring.
@verseve and @JoostBuitink, we discussed this before but please also see the above comment from @shartgring.

[JoostBuitink]

This is indeed a valid comment: the names "lakes" and "reservoirs" are more linked to functionality and not so much to what they are in reality.

I agree that a name such as "waterbodies" is more suitable if we want to combine these functionalities. However, this would mean that there would be a lot of (different) functionality behind the same "name". This is not directly a problem I think, but we need to critically evaluate how we want to setup the "user-experience/input data/toml" to make sure the correct information is provided to wflow for each functionality.