Problem with Baseflow and Quickflow estimates

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).

I’d appreciate any support on this matter. Cheers!

Hi @gabriel_1610,

A couple of things to check:

  • 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

Hey @esoth, thanks for the reply!

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!

Hi @gabriel_1610,

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!

3 Likes

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.

4 Likes

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:


I assume this is incorrect but have no idea where the error is coming from. Any suggestions?

Hi @gabriel_1610,

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.

Cheers,

Doug

1 Like

@gabriel_1610,

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?

Cheers,

Doug

1 Like

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.

2 Likes