While setting up and debugging a relatively large Ribasim model, I found the following simple post-processing check very useful for quickly identifying Basins that may require further investigation.
Basin results can of course be inspected spatially in QGIS using the analysis/visualization functionality. This is very useful for understanding the spatial behaviour of the model and, for example, visualizing hydraulic bottlenecks, shortages at UserDemand nodes, or presenting final model results.
During model development, however, I found that I needed a somewhat different workflow. After almost every model run I wanted to quickly answer: which Basin should I investigate first?
Using QGIS for this required reloading the new results after each run and adjusting the Basin visualization again. For repeated model-development runs this became relatively cumbersome.
A simple table based on basin.nc provided a very quick first screening:
basin_results = xr.open_dataset(out_path / "results" / "basin.nc")
rows = []
for basin_id in basin_results.node_id.values:
level = basin_results["level"].sel(node_id=basin_id).to_series()
start = level.iloc[0]
end = level.iloc[-1]
maximum = level.max()
minimum = level.min()
rows.append({
"basin_id": basin_id,
"start": start,
"end": end,
"max": maximum,
"min": minimum,
"max_above_start": maximum - start,
"max_below_start": start - minimum,
"time_max": level.idxmax(),
"time_min": level.idxmin()})
basin_check = pd.DataFrame(rows)
print("\nLargest increases above initial level:")
print(
basin_check
.sort_values("max_above_start", ascending=False)
.head(30)
.to_string(index=False))
It would then look something like:
Largest increases above initial level
| Basin |
Initial level [m] |
End level [m] |
Max level [m] |
Max above initial [m] |
Time max |
| 938 |
97.00 |
99.48 |
160.39 |
63.39 |
1995-02-01 |
| 1249 |
14.93 |
13.93 |
64.68 |
49.75 |
1995-02-02 |
| 415 |
97.00 |
... |
142.55 |
45.55 |
1995-02-01 |
| 593 |
97.85 |
... |
142.54 |
44.69 |
1995-02-01 |
| 1162 |
25.00 |
... |
64.64 |
39.64 |
1995-02-02 |
Largest decreases below initial level
| Basin |
Initial level [m] |
End level [m] |
Min level [m] |
Max below initial [m] |
Time min |
| 557 |
120.00 |
65.71 |
65.71 |
-54.29 |
... |
| 614 |
120.00 |
66.81 |
66.81 |
-53.19 |
... |
| 564 |
120.00 |
71.48 |
71.48 |
-48.52 |
... |
Sorting the Basins by max_above_start immediately provided a shortlist of locations to investigate. I could then go to those nodes in QGIS and use the spatial visualization to understand what was happening in the surrounding network.
The time_max information was also useful. In several cases, multiple Basins reached unusually high levels at approximately the same time. This helped indicate that they were affected by the same downstream hydraulic restriction rather than representing independent Basin problems.
In this model development phase, I think I found the two approaches quite complementary:
first run model, then check quick tabular screening, identify suspicious nodes, inspect those locations spatially in QGIS, then adjust schematization and rerun.
This helped considerably when tracking down hydraulic bottlenecks in the schematization.
For analysis of the final model results I would still expect the spatial visualization to be more useful, particularly for communicating spatial patterns such as water shortages. But during model setup and debugging, a small automatically generated diagnostic summary after each run could be a useful addition to the workflow.
This is not really a Ribasim issue, but I wanted to share the workflow because it proved quite useful when developing a larger model. It made me wonder whether a simple “Basin levels check” in the Ribasim log could be useful: a short summary of Basins showing the largest level increases or decreases during the simulation, including when these occur. This could serve as a quick first screening before investigating suspicious locations further in QGIS.
Side note:
As a side observation, I occasionally saw Basin levels dropping below the lowest level defined in the Basin profile. I did not investigate this further, but this behaviour gradually improved as hydraulic bottlenecks were resolved, particularly when several fixed-flow Outlets were replaced by TRC's. But I cannot say whether this was related to the Outlet representation (does it have bounds -inf?) or another aspect of the schematization.
While setting up and debugging a relatively large Ribasim model, I found the following simple post-processing check very useful for quickly identifying Basins that may require further investigation.
Basin results can of course be inspected spatially in QGIS using the analysis/visualization functionality. This is very useful for understanding the spatial behaviour of the model and, for example, visualizing hydraulic bottlenecks, shortages at UserDemand nodes, or presenting final model results.
During model development, however, I found that I needed a somewhat different workflow. After almost every model run I wanted to quickly answer: which Basin should I investigate first?
Using QGIS for this required reloading the new results after each run and adjusting the Basin visualization again. For repeated model-development runs this became relatively cumbersome.
A simple table based on basin.nc provided a very quick first screening:
It would then look something like:
Largest increases above initial level
Largest decreases below initial level
Sorting the Basins by max_above_start immediately provided a shortlist of locations to investigate. I could then go to those nodes in QGIS and use the spatial visualization to understand what was happening in the surrounding network.
The time_max information was also useful. In several cases, multiple Basins reached unusually high levels at approximately the same time. This helped indicate that they were affected by the same downstream hydraulic restriction rather than representing independent Basin problems.
In this model development phase, I think I found the two approaches quite complementary:
first run model, then check quick tabular screening, identify suspicious nodes, inspect those locations spatially in QGIS, then adjust schematization and rerun.
This helped considerably when tracking down hydraulic bottlenecks in the schematization.
For analysis of the final model results I would still expect the spatial visualization to be more useful, particularly for communicating spatial patterns such as water shortages. But during model setup and debugging, a small automatically generated diagnostic summary after each run could be a useful addition to the workflow.
This is not really a Ribasim issue, but I wanted to share the workflow because it proved quite useful when developing a larger model. It made me wonder whether a simple “Basin levels check” in the Ribasim log could be useful: a short summary of Basins showing the largest level increases or decreases during the simulation, including when these occur. This could serve as a quick first screening before investigating suspicious locations further in QGIS.
Side note:
As a side observation, I occasionally saw Basin levels dropping below the lowest level defined in the Basin profile. I did not investigate this further, but this behaviour gradually improved as hydraulic bottlenecks were resolved, particularly when several fixed-flow Outlets were replaced by TRC's. But I cannot say whether this was related to the Outlet representation (does it have bounds -inf?) or another aspect of the schematization.