Strange value in SDR model

syhluke · September 2018

Hello guys!

I'm now researching on DMZ area in Korea peninsula with SDR model.

I got a successful message but the value of usle is somewhat weird

I tried to find what is wrong but... It didnt work

(I've tried changing value of Soil erodibility factor, P value...)

Here's ulse image I got from SDR

As you see, usle has only one value..

Please help me.

syhluke · October 2018

and here's the attribute table of watershed_result

Only one subwatershed has a value, but others don't. (rather, they have -1)

I'm wondering why this happens...

swolny · October 2018

Hi @syhluke -

I don't see an attachment with your first post about USLE.

That's strange about only one of the watersheds having a value. Would you please post your whole logfile so we can see what version of InVEST you're using and if there are any messages that would help debug? Thanks.

~ Stacie

syhluke · October 2018

Thanks for your response!

Here's my log file

syhluke · October 2018

I attach my sed_retention image file again and latest log file. I only changed soil erodibility factor...but,,, the value is still unreliable...

I use Invest ver. 3.4.4

Flow acc threshold is 10000 and I put a default value for k, IC0 and Max SDR value.

Thanks again for your help

swolny · October 2018

Does the watershed_results_sdr shapefile have values in it that look reasonable?

And what does stream.tif look like? Does it have a good, connected stream network defined?

~ Stacie

syhluke · October 2018

Thanks @swolny again for your reply

I checked my watershed_result shp file, but a usle value is quite large... it is about 1245 tonnes/ha/yr(I divided the usle value with a watershed area(ha))! I attached my result image file. The stream. tif looks fine. All streams are connected and they seems to be well-matched with real streams. Here's my result.

ws_id	Shape_Area(Ha)	sed_retent	sed_export	usle_tot
1	238313.8633	-1	-1	-1
2	93991.68842	279340267	4396021.969	117091017
3	158641.4546	-1	-1	-1
4	93030.5224	-1	-1	-1
5	82640.85604	-1	-1	-1
6	207258.2829	-1	-1	-1
7	245152.5872	-1	-1	-1
8	141935.9516	-1	-1	-1
9	14643.74171	-1	-1	-1
10	185079.9294	-1	-1	-1

Only one watershed has a value and others -1, and even usle is quite different from the average value of South Korea(32tonnes/ha/yr). I'm really frustrated..

Dose my problem have to do with rasters with different cell size?

Or do I have wrong understanding with my result?

swolny · October 2018

There could be a variety of reasons for the high value, could be high values of model inputs, could be that the model doesn't work well in this type of topography. Also remember that models need to be calibrated with observed data, because model results rarely match the real world without it.

Maybe easiest is for you to send me your data and I'll try running it. In the SDR app, do this:

- File -> Save As

- Datastack type: Data archive

- Save the dataset

Then either send it to me at swolny at stanford.edu or post it to Google Drive/Dropbox/whatever and send me the link.

~ Stacie

syhluke · October 2018

Dear Swolny

I send u an email now and please check.

Thanks for your help

Regard

swolny · October 2018

Hi @syhluke -

I'm testing your dataset, and found a few things.

The K factor raster caused problems for me. I'm not sure what's wrong with it exactly, but when I substituted a different raster for K, there were more reasonable values in the output rasters and USLE values for all watersheds in the output shapefile. But still only sed_export and sed_retent for one watershed.

Then there was trouble with the watersheds shapefile in Arc. When I tried exporting it to a new shapefile, it would only export two of the watersheds. There were characters in some of the fields that I thought might be an issue, so I deleted all of the fields with those characters, and was then able to export all of the watersheds to a new shapefile. But this did not fix the problem.

I also looked closely at the intermediate and final output rasters, and see a strange linear pattern all over the watershed, that is probably caused by the DEM, possibly from reprojecting it and choosing "nearest neighbor" for resampling instead of "bilinear" or "cubic". Zoom in on sed_export.tif or slope.tif to see what I mean. I cannot fix this, you need to go back to the original DEM and try reprojecting again. If that doesn't help, then the original DEM data might be bad, and you might try a different one.

All of this needs to be done, but I'm still not convinced that the DEM is the cause of the missing data in the watershed shapefile, since the sed_export and sed_retention rasters came out ok (although with that weird linear pattern, and some very high values that skew the symbology) and should have been able to be aggregated. So I've passed your data to our software team and hopefully they'll have a better idea of what's going wrong there.

In the meantime, please try making a new K TIFF and work on the DEM.

~ Stacie

syhluke · October 2018

Hi @swolny

I really appreciate your help!

tried the way you taught me(Put a K raster as tif format, delete unnecessary fields in watershed attribute table, and choosing "bilinear" for resampling when reproject DEM raster) but there's still one value and others -1.

and the value of the subwatershed changed but still unreliable (it is 978 tonnes/ha/yr..). I wonder how you get the reasonable value. May I ask your usle result with your new K raster? What was your reasonable value?

Best regards,

syhluke · October 2018

Hi @swolny

I tried to figure out why my watershed result has a problem, and I had doubt on my watershed map since it is too small (or too appropriate) to give a reasonable result. (but I'm not certain..)

So I've changed my watershed map into a more detail watershed, and I bumped into KeyError :1.

but new files appeared such as

Here's my log file and could you please give me any help? aligned_dem, aligned_erodibility, aligned_erosivity, aligned_lulc, cp, s_accumulation, s_inverse, w_accumulatiom, w_threshold, ws_inverse, zero_absorption_source. tif

and I wonder how long does it take to get an answer from your software team?

Thanks!

swolny · October 2018

Hi @syhluke -

We were all out at a work retreat last week, but I've passed along your data and hopefully they can figure it out.

As for the KeyError, lots of other people have had that error, so search the forum and see if any of their solutions work for you.

~ Stacie

carlureta · November 2018

Hi Stacie,

I'm following this thread because I also get a similar result for the shapefile where the USLE, sed ret, and sed export values are -1. This is my 5th time to run the SDR model but this is the only time that I got that result. The results from previous runs were fine except for this one (you actually helped me out also when I was trying to make the model run - Thanks for that!). Do you have an update from the software team on why we get -1 value on the shapefile? The raster files produced seem to make sense though, but the shapefile values do not.

I did couple of trial and error to troubleshoot this and found that my BP table has an extra LU code for "nodata" which has usle_c and usle_p values as 0. When I took that out, it seems I got the values that I want in the shapefile for USLE, sed ret, and sed exp. Maybe they are connected?

Hope this experience helps in troubleshooting.

Thanks for all the assistance!

~ Carl

carlureta · November 2018

Hi,

Just a quick update for the -1, since I'm comparing SDR results in different landcover potentials, I had to change LC inputs. When I use a difference LC, the sed export and sed retention values in the shapefile becomes -1 but the USLE_tot has a some value in tons/watershed. I'm not sure if the LC and -1 are related but I hope this information helps.

Thanks!

swolny · November 2018

Hi everyone -

Our software team has a development version of InVEST that might fix the -1 problem. Please try it out and let us know if it helps you:

http://data.naturalcapitalproject.org/nightly-build/invest-forks/richsharp/InVEST_3.5.0.post709+hbc41e54bcc6c_x86_Setup.exe

~ Stacie

Strange value in SDR model

Comments

Howdy, Stranger!

Categories