Hello everyone. I’m having issues with applying the SWY model on my study area using data that was already applied in the same study area by a colleague but yielding different results. First of all, my QF raster is applying estimates outside of the defined watershed, with black regular structures with values equal to 0. Other than that, the quick flow on my estimate and on my colleague’s is, although similar, yielding different results.
Additionally, I’ve been having the most issues with the baseflow, which not only differ strongly from my colleague’s in appearance but also in values, where my estimates are mostly on the lower end of the spectrum and her’s are more natural and similar to what we expect for the watershed (picture below, mine are “_teste_3.tif”, the ones on the left).
Can you confirm which version of InVEST you and your colleague are using, and that they are the same?
Make sure that you are using the same values for threshold flow accumulation, alpha_m, beta_i, and gamma, as well as the same file inputs. The black rectangular areas in your raster make me think that one of your inputs might have data there.
If everything is the same there, could you please share your logfile and data so that I can try to reproduce the issue? You can post a link to it here, or email it to me privately: esoth @ stanford.edu
No, we aren’t using the same version of InVEST. She worked with the tool back in 2017 and I’m only using it now (the latest version released), but I don’t think I should be getting wrong estimates because of that, it’s most likely problem with the inputs as you said.
Speaking of which, I managed to track down what input was causing the black rectangular areas, and it was the precipitation rasters. I clipped those out and now the results don’t have them anymore. Unfortunately, all the other issues still apply. I’ll email you the data I’m using and the logfile as well.
Again, thanks for the reply and the help!
Thanks for sharing your data! There is indeed something going wrong here.
Several of your monthly precipitation rasters have extremely large negative nodata values (-1.797693e+308). Due to a bug in the model, the number is so large that it’s being rounded to -infinity, resulting in the precipitation from those months not being counted toward the yearly total. Since 𝐿𝑖=𝑃𝑖−QF𝑖−AET𝑖, and 𝑃𝑖 is reduced by this bug, you are getting values of 𝐿 that are very small or 0. This is probably what’s causing your low baseflow values.
This is an error on our part, and we will correct it to handle large nodata values in a future release of InVEST. In the meantime, you can try setting a different, smaller nodata value (e.g. -1) for those rasters.
I also noticed that for the other precipitation rasters your nodata value is 255. Since 255 is a valid value for precipitation, I would recommend you set it to something else, so that it won’t conflict with your actual data. A small negative nodata value e.g. -1 is good for precipitation because actual precipitation measurements are always non-negative.
It’s worth noting that there have been many updates to InVEST since 2017, including some bug fixes that could also make your results different from your colleague’s.
Please let me know how that goes!
As @esoth mentioned, a big change from the 2017 model until now is the introduction of MFD from D-infinity. MFD more accurately measures hydrological flow in lower slope areas and helps to bias against sensitivity of error in all the input rasters. It does this by allowing more paths to flow around the raster and hence has a smoothing effect on data error much like blurring a digital photograph. And depending on which 2017 version you were using, in Dec 2017 we allowed for negative L_avail values where as the Feb 2017 release did not (that was a design bug).
So all those together would cause differences between your colleague’s data and your results. Given all of that, all the InVEST hydrological models should not be used to compare direct results unless the model was calibrated to stream gauges. It’s otherwise fine to compare relative results, but I’d make sense to compare the relative results between the same version of the models.
Thank you, everyone, for your replies! It has helped me a lot in using the program and better understanding it.
Though I have seen better results using smaller nodata values (-1 on all precipitation rasters) I still think the baseflow estimates are a bit off, as well as the local recharge. As you can see below, the L_avail_sum forms an oddly looking map, whilst in the Table of Contents it indicates that the raster contains negative values, which are not supposed to happen on the L_avail according to the model documentation:
Sorry you’re still having issues here. Have you made any other changes to your data other than the precip nodata values? I’ll give it a run on our end and see if I’m coming up with the same results you’re seeing.
It looks like the User Guide might be a little out dated with that “non-negative” comment. It is biophysically possible for L and thus L_sum_avail to be negative and indicates that you’re losing more water than you’re replacing. From what I can tell the negative values are occurring where the stream is being defined. Tagging @rich in case he has any more insight.
The map you provided seems to be typical of how those maps can look for L_ outputs. Can you say more about why you think Baseflow might not be correct?
Hi @gabriel_1610, it’s true Li and hence L_avail and hence L_avail_sum can be negative. But the number in your example is -0.00001 which is insignificant at a landscape level calculation. I’m guessing there’s numerical noise in the DEM somewhere and by coincidence there is a very short flow path that yields a slightly negative value of Li. This is annoying when looking looking at the table but for your example I wouldn’t say it’s numerically significant.
And yes the user’s guide is outdated. We used to force Li to be positive but realized that was biophysically incorrect in cases since it is possible to be losing more water than the pixel is gaining. It looks like I missed a spot there. I’ll patch it now.
Thanks again @rich and @dcdenu4 for the replies! Sorry I took so long to follow up with a response.
I see now that it was a problem with the user’s guide then, thanks for telling me that. That said, maybe I’m having issues interpreting the outputs then because there’s still some confusion for me regarding the values I’m seeing in the rasters, more specifically in the sum rasters of B, L and L_avail.
The main confusion I’m having is related to how high these values are, with both B_sum and L_sum resulting in a mean of approximately 339600 mm. Is this the case where I should look at these as relative and not absolute values and, if so, relative to which other values?
Other than that, I understand how negative values on the local recharge rasters indicate that on specific pixels the loss of water is bigger than the replacement of it, but on a B_sum map which, in my understanding demonstrates the baseflow on the watershed, what do these negative values mean if the water has already achieved the deepest layers of the soil integrating the baseflow?
Sorry no one replied back to your questions! Thanks for reminding us.
You are correct in that the B_sum values should be thought of as relative and that B_sum for a pixel i, the value is the Baseflow contribution of ALL upslope pixels that go through i. From the Users Guide:
B_sum_[Suffix].tif (type: raster; units: mm, but should be interpreted as relative values, not absolute): Map of B_sum values, the flow through a pixel, contributed by all upslope pixels, that is not evapotranspirated before it reaches the stream
Most InVEST models are designed for the watershed or subwatershed scale, so I think relative here might mean to take the individual pixels values with a grain of salt. Depending on cell size and the DEM, the routed flow and thus B_sum could be different due to slope and pixel area.
Certainly if you think the value ranges coming out of the model are suspect and could be a bug, I’m happy to dive into this further. Please let us know if you still have questions / concerns.
