High Water Threshold

[shawncrawley]

While working with Katherine to tackle the work updating the derived.recurrence_flows_conus table (see issue #711), we stumbled upon a couple of questions that I want to make sure are properly addressed and squared away.

First, I did some digging into what services use this table and how. I found that while 35 services use the table, only 13 of them are filtering on where high_water_threshold > 0. The other 22 do not. See the image below, where the highlighted entries are those that do not filter.

Whether or not services are filtering on high_water-threshold > 0 or not is irrelevant from the standpoint of what is currently running in production since we already filter out all reaches with streamflow below 0.001 cms upon forecast ingest (see this configuration line here). That being the case, any reach with a non-0 high water threshold would never be considered anyway and thus never light up.

However, with the changes being made in #711, we would be setting all high water thresholds of 0 to 0.35. Thus, many reaches that were being ignored because they had a 0 threshold will now actually be considered and thus could actually light up. While I believe that what I'm describing here is not a side-effect, but rather the main motivation for the change, I want to be sure.

Back to the filtering that happens on ingest, that of removing reaches with a streamflow below 0.001 cms. I wanted to confirm why that value was chosen. Katherine was pretty sure she heard that the minimum non-zero value that the NWM outputs is actually 0.01 cms, which puts into question why we would even have a filter of 0.001 cms. Did this change between NWM versions or something?

Overall, I just want to make sure we're all on the same page regarding what is being filtered out of our services. Let me know if you have any answers.