Closed hboisgon closed 8 months ago
Hi @hboisgon,
I saw this come up in my github mentions, so just a drive-by comment. There's a UGRID1D topology in xugrid: https://deltares.github.io/xugrid/api.html#ugrid1d-topology
The Ugrid1d functionality is rather barebones now, but I think ideally it could help with these kind of workflows. I see several explicit Python loops here (e.g. via .apply
). Ideally, we could avoid those by making smart use of the Ugrid1d topology and offload most of the work to numba-celltree or something. I'm curious to hear which set of operations you'd require for that to work.
Might be worth some xugrid issues or even a short meeting!
Hi Hélène @hboisgon ! I am testing/using this feature for coupling Wflow to a Delft3D FM model. It worked nicely with my geodataframe out of the box with the subbasin approach. However, in order to use the river nodes approach, the geometries have to be ordered to be able to loop them. Or at least, that is how I interpreted the following error that I got:
NotImplementedError: Sub-geometries may have coordinate sequences, but multi-part geometries do not
I solved this by applying .explode()
to the geodataframe as suggested here: https://gis.stackexchange.com/questions/378806/multi-part-geometries-do-not-provide-a-coordinate-sequence-error-when-extracti . So, it might be useful to implement .explode() in the hydromt_wflow workflow to prevent these errors. Attached also a zip with the geojson of the geometries that I am using in case you are interested 1D_branches_clipped_20240220.zip
Hi Hélène @hboisgon ! I am testing/using this feature for coupling Wflow to a Delft3D FM model. It worked nicely with my geodataframe out of the box with the subbasin approach. However, in order to use the river nodes approach, the geometries have to be ordered to be able to loop them. Or at least, that is how I interpreted the following error that I got:
NotImplementedError: Sub-geometries may have coordinate sequences, but multi-part geometries do not
I solved this by applying
.explode()
to the geodataframe as suggested here: https://gis.stackexchange.com/questions/378806/multi-part-geometries-do-not-provide-a-coordinate-sequence-error-when-extracti . So, it might be useful to implement .explode() in the hydromt_wflow workflow to prevent these errors. Attached also a zip with the geojson of the geometries that I am using in case you are interested 1D_branches_clipped_20240220.zip
Great, thanks @shartgring for also testing it out and glad the subbasins method worked well directly for your case too :) Seems like a good idea to add this explode() part so I will!
Issue addressed
No issue published
Explanation
This PR introduces a new function to connect wflow to 1D type of model (like Delft3D FM 1D, HEC-RAS, etc.) In this function a user has two choices to connect:
In this function, gauges can be added and river discharge saved, for the subbasins, two versions are produced, one with all cells and one with river cells only so that wflow can save river.inwater to give the 1D model all water coming into the river (ie the 1D model can then do its own routing and river evaporation). This has been developed and tested to connect to Delft3D FM for both 1D boundaries and 2D laterals from the subbasins inwater.
Checklist
main