Support of hydrological concepts in v1.0.

[verseve]

Internally (at Deltares) and externally the wflow_sbm model is used mostly and most development efforts (capacity/budget) are aimed at the SBM concept, including the coupling to other software packages. This is also the case for the Wflow model builder that supports the automatic setup of a wflow_sbm model.

It would be good to discuss (and decide) whether we want to support the other hydrological concepts HBV and FLEXTOPO in v1.0.

[JoostBuitink]

Thanks for starting this discussion! Just putting my "two cents" down here:

• We frame Wflow.jl as a hydrological framework, that supports multiple concepts. While I agree that we put most of our efforts into SBM (also for model building), I still believe that the framework is something that could potentially be very strong. This is of course more with a scientific style questions in mind
• We want to decouple the vertical and horizontal components, where we expect to put our emphasis on the SBM concept. How much work would it be to keep the HBV and FLEXTOPO concepts in there, but don't do the same amount of refactoring as we plan to do for SBM? We could throw a warning that these concepts are not actively developed.
• I believe we had some external users using the HBV concept (without any guidance from Deltares, as far as I am aware). I don't recall their name, I'll dig through my inbox to see if I can find anything. Might be good to hear their opinion as well!

[verseve]

Thanks for putting your "two cents" here @JoostBuitink !

Below a response from my side to your points:

• I agree, a hydrological modelling framework/platform with multiple vertical hydrological concepts could potentially be very strong. On the other hand, in the wflow Python version many more vertical hydrological concepts were available, also added during (research/thesis) projects, but in the end not used that much (except for wflow_sbm). These others concepts were also behind on recent developments (for example changes to the kinematic wave routing were only implemented for wflow_sbm and not for wflow_hbv, wflow_topoflex etc.). Actually, this is also the case for HBV and FLEXTOPO in Wflow.jl with respect to routing options (so in that sense not very different from the Python implementation). From a scientific point of view I think it would be more interesting to support different concepts at a lower level (still a framework), for example different snow, glacier, interception etc. concepts, ideally implemented with the use of DifferentialEquations.jl (which may also open the door (easier) to the use of machine learning techniques).
• Indeed, it could be an option to keep HBV and FLEXTOPO without changing the code for these concepts much. However, if we plan to not actively develop these concepts further, we may as well freeze these concepts in the latest version before moving to v1.0? Also in light of maintenance and clean code I think that would be the preferred option.
• I agree, always good to get feedback on this from (external) users!

[markhegnauer]

Hi all,

Interesting discussion! Here my response:

• I agree with Willem that presenting wflow as a framework at a lower level would be very strong. In a way we are doing this already for the lateral concepts, which in my opinion works really well! It would be great if we can easily swap other concepts (e.g. for snow, groundwater, etc.) with more sophisticated methods as easily.
• In terms of keeping the other concepts: In the ideal world with unlimited time and budget for developments, I would say yes. But if we need to prioritize, I would definitely drop these concepts and focus on, in my view, more relevant developments, such as the coupling to (or integration of) water allocation models (e.g. RIBASIM). This really fills a gap in the current wflow framework and is very relevant for many studies around the world. Dropping these concepts would, for less scientific users, also highly improve the understanding of wflow and reduced the confusion some users have. Especially, since we do not provide any support in terms of model building etc. for these other concepts.
• To continue the discussion on HBV: What does HBV bring in terms of (scientific) added value? Are there any processes that we cannot simulate with SBM? So, what is the added value of having HBV in the framework, other than to be able to compare with the SBM model (which was very useful to transition away from the HBV concept)?
• And if we do want to have more concepts in the framework, making the decision right now, would HBV (and/or TOPOFLEX) be our first choice? Or are there other concepts that are more logical to implement in the wflow framework, and we basically drag along HBV (and/or TOPOFLEX) from a historical choice that was made?

To summarize, I would not be too sad (or would even be happy) if we drop the other concepts and focus on (in my view) more relevant developments. Of course, we should support users with the transition to SBM if they want to upgrade their models to a newer version.

[shartgring]

I fully agree with the comments on flexibility in the framework being of added value. And I can imagine that flexibility in implementation of custom concepts can result in MSc/PhD students exploring new directions within the use of Wflow. Not only for vertical processes but also horizontal processes such as modelling of reservoirs (speaking from personal experience 😉). So I would agree that a good priority may be to focus on sbm and remove other concepts resulting in easier code that is also easier for development and research

If I understand the code correctly, there is the distinction between vertical concepts (sbm, hbv, flextopo) and between different model types (sbm_model, hbv_model, flextopo_model but also sbm_sediment and sbm_gwf). I think it is relevant to keep in mind if dropping the hbv and flextopo concepts, and simplifying the code accordingly, may also affect the structure in which sbm_sediment and sbm_gwf are implemented. Is that something that may also be affected, or is that a different discussion?

[laurenebouaziz]

hi all,

I understand the discussion considering the limited time and money available for future developments in wflow. I also think it would be very strong to make further developments at a lower level to have more concepts for e.g. snow module etc. However, I also think having a completely different concept in the framework can be of added value if we want to go towards multi model ensembles and evaluate model structure uncertainty. Also interesting to note that in the FLEXTOPO concept, we can also include or bypass reservoirs to tailor the bucket configuration and implement different equations to represent the different processes.

Maybe also good to consider the following:

• wflow_flextopo for the Meuse is currently implemented in RWSoS so I am not sure it would be ideal the remove it from the code as it would imply having two versions of wflow in RWSoS if we make future developments in sbm.
• wflow_flextopo was used by a master student of the TU and her publication is currently under discussion (https://egusphere.copernicus.org/preprints/2024/egusphere-2024-115/)
• wflow_flextopo could potentially be used in GRADE to evaluate model structure uncertainty besides parameter uncertainty for the "werklijn" of the Meuse basin.

Happy to discuss this further with you.

[aweerts]

I understand the discussion in light of limited resources
There is a thin line between wflow code and wflow(_sbm) model building/configuration as mentioned by Willem
Regarding the model building I would only focus on horizontal processes (river, lakes, reservoirs) and on wflow_sbm (vertical +subsurface horizontal part). Not sure how much this is untangled in the discussion here.

Regarding the question whether we want to support the other hydrological concepts like HBV and FLEXTOPO in v1.0?
it is difficult for me to understand how much maintenance is needed and for what purpose? As an example/question, e.g. will the OpenDA ZeroMQ coupling work immediately be available for any concept or does this require additional effort for all concepts? I can not judge that.

If you want to keep selling wflow, as a hydrological framework it is useful to have more than one hydrological concept (e.g. HBV96, FLEXTOPO) that we maintain and included in the code (and a guide how people can add their concept into the framework).

However, you could also frame it as a framework for integrated modelling with wflow_sediment and delwaq and more to be added (like irrigation, crop modelling, water use)? This would require that wflow_sediment and delwaq can be coupled on timestepping basis (this has priority in my opinion!!) For this you don't need another vertical concept.

Being able to run the routing+reservoirs+lakes as a separate model is valuable and could potentially increase the user base . You can use the modeled vertical runoff as forcing from any model (e. similar to GEOGLOWS) or get the runoff from a vertical concept inside the framework like HBV, etc.

HBV96 is interesting from legacy purpose and an occasional user but i don't expect large user base and from that perspective it can be removed from the code

FLEXTOPO is used by TUD/few scientists and but I don't expect large user base and from that perspective it can be removed from the code. For multi-modelling you could argue this should/can be done with the original model from the developers (e.g. as in ewatercylce).

It might be valuable to add for instance Lisflood as vertical concept (and being able to run with the JRC model parameters as these are available/can de downloaded) this could potentially increase our users base and potentially results in projects for/with JRC. This is something you might want to discuss with JRC. I sent them a preprint of the EMS paper. This could also be potentially be interesting for ourselves in EU proposals/projects.

For research it might be valuable to being able to add/test new vertical concepts like julia richards equation Hydpix although I expect not immediately a large user base

So no clear yes or no from my side (yet)

[tanerumit]

Hi,

As a Climate Adaptation Department (CAD) person (non-developer), I have a few things on my wish list for wflow. Perhaps from a more practical point, aside from the conceptual choices reg. HBV, FLEXTOPO.

As a distributed and physically-based framework, wflow to me is well suited for spatially explicit, detailed short-term hydrological assessments. However, our current "one-size-fits-all-all" approach is not ideal. For example, for the purpose of long-term policy analysis or as part of planning tools (e.g., FloodAdapt, Stress Testing Tool, Ribasim, etc.), we need to think differently. Such use cases shall also be considered when making development choices. I'd like to see more flexibility and guidance to reduce model-run times when preferred. For example, to allow better handling of large basins (e.g., Danube, Niger, Ganges), longer simulations (e.g., +50 years), and many simulation runs.

Some options I can think of:

• Ability to switch off or change certain processes (vertical, horizontal, routing, etc.) that are bottlenecks. We need to better understand what we can sacrifice in terms of realism and what we can't.
• Ability to employ a coarser time-step on-demand (e.g., week, biweekly)
• Ability to make certain parts of the model semi-distributed rather than being completely grid-based (on-demand).

[alimeshgi]

Thanks @tanerumit for sharing your insights and wish list for the wflow framework. I agree that there is a need for more efficient modeling approaches, especially for planning tools.
One potential solution to improve computation speed is the inclusion of simpler and quicker routing concepts. Additionally, we have recently explored the use of Graph Neural Networks (GNN) as an emulator for wflow in a master’s study. The preliminary results are promising, showing improvements in computational time. This suggests that further research and analysis on GNN could be a valuable direction for planning tools. But let’s further discuss the options together.

[verseve]

Hi @tanerumit ,
Thanks for your contribution to this Discussion, it is good to be aware of these practical points related to long-term policy analysis and planning tools. Below a short response to the options you mentioned:

• For v1.0 we plan to fully decouple the vertical concept from routing (related to your first point), see also issue Fully decouple vertical and horizontal components #225. This may already help to reduce model run times for the coupling with Ribasim (if Ribasim takes fully care of routing) or when a user wants to couple it to an external (faster) routing module.
• I think a coarser time step could work for the surface routing by making use of a simpler routing scheme than kinematic wave or local inertial. Generally, routing takes most part of the computational time. Another option is to decouple the routing from the grid (vector based) see also issue vectorized routing per branch #227. Not sure if a coarser time step for the vertical concept is recommended, I think a while ago we decided this was not recommended, probably @markhegnauer can confirm?
• Instead of semi-distributed I would recommend to first look into a coarser grid size (> 5 km). For this, we probably need to look into sub-grid functionality (vertical and maybe also part of routing (e.g. subsurface flow)). I expect this takes less effort than supporting a semi-distributed hydrological model (both model builder and kernel).

Finally, it would be good to know what the requirements are related to model run times, model output (variables) and hardware for these use cases. For example, if GPU is allowed, this could also be an option to speed up the code.

[verseve]

Did not see @alimeshgi response yet when responding, but yes, use of GNN could be an option. I agree, further discussion of these options would be good.