We iterate over the flow values, and evaluate (element < minQ). (element is the current flow value in the iteration). If it’s less than minQ, depth = 0.
In the supplied flood model parameters, minQ ranges from 50 to 300. It is never less than 50.
The maximum river_flow prediction in the data is:
manyfews=# SELECT max(river_flow) FROM calculations_riverflowprediction;
max
-------------------
11.36072198233463
(1 row)
So of course there are never any floods reported, not even in the river channel! There’s never a flow prediction exceeding minQ.
So, question: how is minQ supposed to be used? It’s obviously being used incorrectly right now, because even in the river channel, depth will always be set to zero.
I think I’ve seen this issue before. I believe we never solved it, but we did forget about it.
Describe the bug There is a bug in how minQ is used, or an error in the magnitude of the minQ values in the supplied parameter CSV.
minQ is being checked against the predicted flow values: e.g.
[ 8.52716213 8.81309132 … 8.32940905 8.92300271 9.10568886 ] (100 values total)
We iterate over the flow values, and evaluate (element < minQ). (element is the current flow value in the iteration). If it’s less than minQ, depth = 0.
In the supplied flood model parameters, minQ ranges from 50 to 300. It is never less than 50.
The maximum river_flow prediction in the data is:
manyfews=# SELECT max(river_flow) FROM calculations_riverflowprediction; max ------------------- 11.36072198233463 (1 row)
So of course there are never any floods reported, not even in the river channel! There’s never a flow prediction exceeding minQ.
So, question: how is minQ supposed to be used? It’s obviously being used incorrectly right now, because even in the river channel, depth will always be set to zero.
I think I’ve seen this issue before. I believe we never solved it, but we did forget about it.