Set up shared module Wflow

[visr]

Mainly getting the infrastructure set up for now.

Starting with:

• [ ] https://github.com/Deltares/Wflow.jl/issues/576
• [ ] https://github.com/Deltares/Wflow.jl/issues/577

Name: WflowLand?

[visr]

@vers-w @JoostBuitink do you have a preference for a name? Perhaps something like WflowLand? Actually Clima has https://github.com/CliMA/ClimaLand.jl/ as well.

I guess I'll start prototyping the concept initially for the Ribasim use, without directly updating Wflow to use it. We'd have to register the shared module as well when Wflow starts using it. We can still consider it internal in the sense that we don't encourage direct usage.

[vers-w]

@vers-w @JoostBuitink do you have a preference for a name? Perhaps something like WflowLand? Actually Clima has https://github.com/CliMA/ClimaLand.jl/ as well.

I think before we decide on a name for the shared module, it would be good to discuss in a bit more detail (refinement session) what we expect from this module, both from Ribasim and Wflow. During the design session about AquaCrop and irrigation it was mentioned to:

1. Track the soil moisture balance ourselves instead of using the AquaCrop implementation.
2. Work on a lumped hydrological SBM concept (this would extend 1).

I think we could also opt (depending on the shared module requirements) for an implementation in Wflow. Wflow is quite similar to ClimaLand except for the routing part and Wflow is less modular (not using different modules). For Wflow we definitely made some steps like separate components for snow, glacier, soil, etc., but not as separate modules. Using DifferentialEquations could also help with that I think. Anyway, I think good to discuss a bit further.

[visr]

Indeed putting it in Wflow would also be an option to consider. We can do a refinement session but I think having a proof of concept may help making it a bit more concrete as well. One advantage of initially putting it in a separate module is that it will not get in the way of the Wflow v1 effort. Though of course we can branch as well and keep it in separate files. Once it has some form we can then discuss if it should move into Wflow itself or that Wflow should eventually depend on it.

[vers-w]

For the Wflow v1 effort I would say we are almost there (besides a couple of small PRs), so not too worried about that. And indeed it would be good to branch anyway.

I think a meeting soon could help to make this more clear. What functionality do we want to expose and how? And based on that decide what would be the best way forward, also of course considering Ribasim plans and (possible) Wflow plans (for example modular in a similar way as Clima, making use of DifferentialEquations). Any additional thoughts on this @JoostBuitink and Ali Meshgi?