USLE results to high (SDR)

sdr
#1

Hi InVest users,

my results from the usle are to big. for example a agricultural field with almost one hectar has a total soi loss of about 206 t/ha/year (zonal statistics -> sum of the pixels in the field). the mean value for one pixel in this field is about 0.14 t/ha/year. i used a dem with a resolution of 2.5m x 2.5m.

watersheds

the imputdata was as follows: R=746(all area); K=0.27(all area); C=0.26 (agricultural area)
lulc.csv (121 Bytes)

k=2; IC0=0.5; SDR= 0.34

i allready calculated the usle in GIS by myself. with the inputdata especially the c-codes i got quite good results. even the ls-raster from the intermediate_outputs is not to high compared to my ls-raster caluclated in GIS.

the InVest model is calculating succesfully, there is a warning though at the flow acumulation part:

04/20/2019 10:49:09 natcap.invest.sdr INFO calculating flow accumulation
04/20/2019 10:49:09 natcap.invest.pygeoprocessing_0_3_3.routing DEBUG starting flow accumulation
04/20/2019 10:49:14 natcap.invest.pygeoprocessing_0_3_3.routing.routing_core WARNING no flow direction found for 0 2 WARNING no flow direction found for 0 2
04/20/2019 10:49:14 natcap.invest.pygeoprocessing_0_3_3.routing.routing_core WARNING no flow direction found for 0 2
04/20/2019 10:49:22 natcap.invest.pygeoprocessing_0_3_3.routing.routing_core INFO calculate transport cells_to_process.size() = 352
04/20/2019 10:49:22 natcap.invest.sdr INFO calculate ls term
04/20/2019 10:49:22 pygeoprocessing.geoprocessing INFO starting stats_worker
04/20/2019 10:49:22 pygeoprocessing.geoprocessing INFO started stats_worker <Thread(Thread-6, started daemon 11488)>
04/20/2019 10:49:26 pygeoprocessing.geoprocessing INFO 100.0%% complete

not sure if this warning causes proplems calculating the usle…

what do i miss? can anybody help me out here, please?
thank you!

#2

Hi @bastian87,

I can’t really speak to whether or why the USLE has high values in this case, but I can say that the warnings you’re seeing are normal and merely extra logging that no flow direction could be found for a specific pixel, which happens if a pixel does not flow into any pixels at all (like when it’s the downstream-most pixel in a watershed).

You might also be interested to note that we’ve been working on an updated version of SDR that you might want to take a look at. We believe the multiple flow direction routing implementation included there to be more biophysically correct than the D-infinity we had before. The link to the development build is below.

https://storage.googleapis.com/releases.naturalcapitalproject.org/invest/3.6.0.post430%2Bh6444d041f0ee/InVEST_natcap3.6.0.post430%2Bh6444d041f0ee_x86_Setup.exe

As for the whether or why your results are high, could you attach your logfile? That’ll get us started.

Hope you’re well,
James