Negative Values - SDR Output

Software Support
1

I have run the model and I’m getting extreme negative values as per the images attached. I have investigated the input data, and they all seem fine even though they are not at the same resolution. The model did complete with an “errno 13” and I have attached the log as well.

InVEST-sdr-log-2026-03-17–12_17_40.txt (54.2 KB)

SDR_Output2
SDR_Output21707×846 227 KB

SDR_Output1
SDR_Output11750×853 263 KB

2

Hello @Edith_Malemba -

Thanks for including the result maps and log file.

All of the raster results should be output at the same resolution as the DEM that you used as input.

The error 13 message specifically says this:

PermissionError: [Errno 13] Permission denied: ‘C:\Users\SBM\OneDrive - University of Leicester\ArcGIS\Buckie SDR March 2026\BUCKIE_March_26\SDR March output\intermediate_outputs\flow_direction_mar262.tif’

I’m not sure why you would get a PermissionError in particular, but since you are reading and writing to the cloud (OneDrive), a variety of things could happen to cause problems with file access. It does look like you got reasonable model results (except for RKLS), the error happened while creating metadata, and the log file indicates that it finished, so the error should not be causing problems with the spatial results. You could try moving your inputs and output to a local disk instead of the cloud and see if the Permission Error goes away.

Regarding negative values, i see them with RKLS and avoided_erosion, and they are small numbers, not extreme. Still, neither of these should be creating negative values, and most of the study area seems to have a value of 0 (or potentially 1e38, i’ll ask the software team why that’s on the legends), so something odd is going on there. It would be useful to look at the model inputs that go into rkls.tif and see if any of them explain this result:

  • The rainfall erosivity input raster
  • The soil erodibility input raster
  • And the output file intermediate_outputs/ls.tif

Check out these layers in GIS and let us know what you find.

~ Stacie

3

PermissionError: [Errno 13] Permission denied: ‘C:\Users\SBM\OneDrive - University of Leicester\ArcGIS\Buckie SDR March 2026\BUCKIE_March_26\SDR March output\intermediate_outputs\flow_direction_mar262.tif’

I agree, this error did not affect the model’s results, though it probably affected how much metadata was available to display in the report. We will investigate if this is something we can fix on our end. But as Stacie suggested, it may be wise to move the workspace off of OneDrive. In general, InVEST models do a lot of rapid reading and writing of files, and an application like OneDrive that is constantly trying to sync files to the cloud may create problems that are hard to predict.

@Edith_Malemba if you can, we would very much like to see the whole report. Please see these instructions for how to share it.

Thank you,

4

Thanks, @swolny and @dave. I checked my input rasters again and noticed that the weird values may be appearing when I clip them to my DEM. I tried to rerun the model, but it’s giving an error code, even when I tried re-running the previous session that gave the initial results. I also tried to move the inputs to the local disc. I have also attached the full report of the initial run as requested.

InVEST-sdr-log-2026-03-19–11_28_48.txt (30.2 KB)

InVEST-sdr-log-2026-03-19–11_27_25.txt (52.8 KB)

sdr_report_mar262.zip (722.3 KB)

5

Thanks for sharing all this @Edith_Malemba , from the report I can see that three of the input rasters do not have a nodata value defined, but they include pixel values that I’m guessing are intended to be nodata (see the min and max values). Making sure to properly define the NoData value in your input rasters will ensure those pixels are properly ignored by model computations.

I also wonder about the DEM. Does it seem correct that the maximum elevation in your area is 255? It seems like 255 may be intended as nodata. But it also seems like something may have gone wrong when you clipped the DEM, like you said. Values from 0 - 255 are the range of an 8-bit unsigned integer datatype, but you may require a larger datatype (e.g. 16 or 32-bit integer). Anyway, I would go back to your original DEM and check it’s datatype and make sure it has the correct NoData value set, and then make sure you choose the same datatype if you are clipping/exporting it to a new raster.

Minimum Maximum Mean Valid percent Count Nodata value
DEM26.tif 0 255 115.78 100 1.2E+07 3.4E+38
GlobalR_NoPol_ProjectRaster.tif -3.40282E+38 3.4E+38 -3.28067E+37 100 768
K_new_crop_Clip.tif -3.40282E+38 0.0406909 -3.62095E+37 100 2340
ukregionscotland_Clip.tif 0 21 3.19559 100 480000