Urban Stormwater Retention BUG

Software Support
1

Hello, users and developers.

I am using the Urban Stormwater Retention model for my project. For the past few months, I have been noticing an error in the retention volume and runoff output. The error appears with multiple lines displaying extremely large values, which are then translated as #inf (infinity). I noticed that, for a moment, the values are classified as very large numbers, but then they are converted to #inf in versions 3.14.02 and 3.14.03.

After running a new test on version 3.14.0 of InVEST, this error disappeared, and the values were computed correctly for both volume data columns. For example, in the newer versions, the value 34.5698777… (the real value, which appears in version 3.14.0) was displayed as 345,698,777,123,258,555,789 (#inf). It seems to be an issue related to decimal place identification. I hope this information helps.

I suggest that users of this model revert to version 3.14.0 to avoid this issue until a possible fix is provided for the newer versions of InVEST.

If I can provide any further information, feel free to contact me at anievaz@gmail.com or stephanievaz@usp.br.

2

Hi @Stephanie_Vaz and welcome to the forum!

Thanks for posting about this issue. To clarify, are you referring to inf data values in the total_runoff_volume and total_retention_volume attributes in the aggregate.gpkg output?

I noticed that, for a moment, the values are classified as very large numbers, but then they are converted to #inf in versions 3.14.02 and 3.14.03.

Where do you see the values briefly classified as very large numbers? This will be helpful in trying to pinpoint where the error occurs.

Thanks!

3

Hello!
Yes, exactly both total_runoff_volume and total_retention_volume. I noticed the values with altered decimals when I opened the .gpkg in QGIS in the layers tab. After opening the attribute table, you will see the #inf in these columns.
This happens in the more recent versions, not in 3.14.0.

4

Great, thanks! Not sure if you saw my reply to you in this post, but I believe I’ve pinpointed the issue and am working on a fix now. In the meantime, as you noted, version 3.14.0 should provide the correct results.