### Author:  [@bastian87](https://community.naturalcapitalalliance.org/u/bastian87)
#### Post date: [April 20, 2019, 1:19pm UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/1 "2019-04-20T13:19:01Z")
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.
the imputdata was as follows: **R=746** (all area); **K=0.27** (all area); **C=0.26** (agricultural area)
[lulc.csv](https://canada1.discourse-cdn.com/flex031/uploads/naturalcapitalproject/original/1X/c244881350061bee9869623d4790fafc242fc96b.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 \_
_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!
---
### Author:  [@jdouglass](https://community.naturalcapitalalliance.org/u/jdouglass)
#### Post date: [April 23, 2019, 12:22am UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/2 "2019-04-23T00:22:13Z")
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](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
---
### Author:  [@Prime](https://community.naturalcapitalalliance.org/u/Prime)
#### Post date: [November 14, 2019, 12:21pm UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/4 "2019-11-14T12:21:20Z")
Hello!
The same situation happened to me, the result about usle\_tot is too high ,have you solved this problem?
Thanks for your reply!
---
### Author:  [@bastian87](https://community.naturalcapitalalliance.org/u/bastian87)
#### Post date: [November 14, 2019, 2:25pm UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/5 "2019-11-14T14:25:39Z")
Hey! i had some issue with the index values. i think it was the R-Faktor. my result was obviously about 10 times higher. there are some example-files (raster) to download. compare them to your data and you will find the problem.
---
### Author:  [@Prime](https://community.naturalcapitalalliance.org/u/Prime)
#### Post date: [November 15, 2019, 12:46am UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/6 "2019-11-15T00:46:08Z")
Thanks for your message.
I also compared the R-factor with other research in the same field, the value is in the right range,but solpe.tiff and ls.tiff seem to be strange when compared with other research ,so I am confused.
---
### Author:  [@bastian87](https://community.naturalcapitalalliance.org/u/bastian87)
#### Post date: [January 30, 2020, 9:21am UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/7 "2020-01-30T09:21:32Z")
I thought i have, but unfortunately i did not solved my problem with the **high values**.
Calculated with InVest my arable parcels do have an average erosion from 10-200 ton per ha a year. The flattest, most even parcel has about 10 tons per ha a year! Realistically and already calculated “by hand” and Arc (D8 method) the average erosion on the arable-parcels in the catchment is about 1-20 ton per ha a year. **–\> one of my inputdata is 10 times to high!?** The catchment is in Austria/Europe. Meaning all the data is in metric units. it is therefore not a problem of US/metric units.
k=2; IC0=0.5; SDR= 0.8; Threshold flow Acc: 8000 (10m x 10m grid)
Input-data (+ lulc.csv):
[InVEST\_Iinput\_Data.zip](https://community.naturalcapitalalliance.org/uploads/short-url/dgPbYgSEuXTwN2GkCvflCYhu8Wg.zip) (3.2 MB)
log-file:
[InVEST-Sediment-Delivery-Ratio-Model-(SDR)-log-2020-01-29–12\_02\_35.txt](https://community.naturalcapitalalliance.org/uploads/short-url/pwmwZTbZcRxX4eRUFsDDxtsFd1g.txt) (26.1 KB)
- In austria the R-factors are normaly in (kJ/m²)_(mm/a). i corrected that to the Invest unit (MJ/ha)_(mm/a). The precipitation a year in my catchment is about 35inches. a bit less than in the sample datas catchment in Corvallis Oregon (aprox. 51inches).
- The lulc biophysical table mentioned in the users guide “_should be integer_” (so are the sample-data), but integer files causes an error. i changed to float numbers. should be fine.
- The K-factor (erodibility\_SI\_clip) in the sample data is low. What kind of soil is it? **Maybe my K-factors are to high?**
the reason why i am asking so many questions in this forum lately is that i am writing my master-thesis about soil erosion modelling (with InVEST…surprisingly). InVEST is basicly unknown at my university and therefore many colleagues are highly interested about it.
thanks for helping
Sebastian
---
### Author:  [@swolny](https://community.naturalcapitalalliance.org/u/swolny)
#### Post date: [January 30, 2020, 2:33pm UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/8 "2020-01-30T14:33:16Z")
Hi Sebastian -
I would double-check your K factor values. They look similar to the values included in the [User Guide SDR Appendix A table](http://releases.naturalcapitalproject.org/invest-userguide/latest/sdr.html#soil-erodibility-k), which are in US units, and require a conversion factor of 0.1317 to get metric units (which is noted below the table, but maybe not made obvious enough.) The units for both R and K are very confusing!
I’m not sure if this will explain all of the high values you’re seeing, but it might.
~ Stacie
---
### Author:  [@Prime](https://community.naturalcapitalalliance.org/u/Prime)
#### Post date: [June 12, 2020, 12:12am UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/10 "2020-06-12T00:12:36Z")
Hi @swolny ,
Recently, I am confused about the unit in SDR and NDR model. The output files in SDR model include, sed\_export\_[Suffix].tif and usle\_[Suffix].tif, and the unit of these raster files are all tons/pixel as the description in Interpreting Results. But the unit in the equations is tons/ha. So what is the difference and how is this unit transformed?
If the pixel in my data is 30m×30m, should the unit in output raster files be tons/900m2 as the description in Interpreting Results (tons/pixel)? And if the unit of the raster is tons/ha, how is sed\_export in watershed\_results\_sdr\_[Suffix].shp summed as tons/watershed. Same question exsits in NDR model.
Thanks for your reply!
---
### Author:  [@Nametso](https://community.naturalcapitalalliance.org/u/Nametso)
#### Post date: [March 19, 2021, 4:29pm UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/11 "2021-03-19T16:29:10Z")
@bastian87 Hi, did you find a solution for your problems of high values, i’m experiencing the same problem, the soil loss is very high. i crossed checked everything but still the results come out very high.
---
### Author:  [@swolny](https://community.naturalcapitalalliance.org/u/swolny)
#### Post date: [March 22, 2021, 3:26pm UTC](https://community.naturalcapitalalliance.org/t/usle-results-to-high-sdr/41/12 "2021-03-22T15:26:09Z")
Hi @Nametso
Are you seeing high values everywhere, or just in a small number of pixels? It is common for there to be unusually high values in places with very steep slopes. That’s an unfortunate result of basing soil loss on USLE, which was created for places with low slopes, and it does not perform very well on steep slopes. So I often see results where most of the study area has reasonable values, except for steep mountains.
Previously in this thread we talked about checking the units of all of your inputs, and that is important. Also remember that these models need to be calibrated in order to have more confidence in the absolute values. But if you’re seeing uniformly excessive values, then it’s definitely a good idea to look at the values of all of your model inputs. If those seem ok, try looking at the output files in the Workspace’s _intermediate_ folder, perhaps it will give some insight about which step of the calculations is causing the high values.
~ Stacie