After 11 hours of running (it’s a global model), the SDR model failed with this error:
ValueError: The following 1 raster values [128] from “C:\Users\uqawenge\Dropbox~\InVEST\model_outputs\intermediate_outputs\churn_dir_not_for_humans\aligned_lulc.tif” do not have corresponding entries in the value_map: {1L: 0.00155, 2L: 0.00155, 3L: 0.00155, 4L: 0.00155, 5L: 0.00155, 6L: 0.08, 7L: 0.08, 8L: 0.08, 9L: 0.08, 10L: 0.08, 12L: 0.26, 14L: 0.26, 16L: 0.5}
2019-11-07 22:02:32,826 model._logged_target(1642) INFO Execution finished
2019-11-07 22:02:32,829 utils.prepare_workspace(115) INFO Elapsed time: 11h 30m 34.68s
It managed to create the stream.tif output and that was it. What has gone on here?? Also, I remember seeing something about using part of a past model run to speed up the next run- how do I do that?
This error is coming from a reclassification somewhere in the SDR model (we’ll need to see the logfile that the model produced to say exactly where the reclassification is failing). It’s saying that the reclassification failed because your LULC raster has some pixels with values of 128 and that a value of 128 is not in your biophysical table.
The most common causes for this are:
Your LULC raster does not have a nodata value defied and 128 should represent this value. If this is the case, then all you have to do is define a nodata value within your raster and re-run the model.
Your LULC raster is formatted as a signed byte raster. GDAL, the library we use for reading and writing raster and vector formats, does not have a concept of a signed byte, and so sometimes issues with nodata values come up like this. If this is the case, the solution would be to re-export your raster as an unsigned byte or integer raster and re-run the model.
Re-running the model should take less time, by the way … it should mostly pick up where it left off.
Thanks for the reply. I am working with Amelia who is on a flight to Rome right now, still running it on her computer. We have tried both solution 1 & 2 above. 1) The raster does have no data values. But we tried to reclassify the raster just in case and copy the raster in gis. When we copied raster, there is a -128 NoData Value (optional) that we removed from the input - the output for some reason gives all the previously ‘NoData’ values a value of 0. We then reclassified to NoData. 2) We changed the LULC.tif file to an unsigned integer, it was a signed integer. Then reran in Invest - however still getting same error : “C:\Users\uqawenge\Dropbox~\InVEST\model_outputs\intermediate_outputs\churn_dir_not_for_humans\aligned_lulc.tif” do not have corresponding entries in the value_map : {1L: 0.00155, 2L: 0.00155, 3L: 0.00155, 4L: 0.00155, 5L: 0.00155, 6L: 0.08, 7L: 0.08, 8L: 0.08, 9L: 0.08, 10L: 0.08, 12L: 0.26, 14L: 0.26, 16L: 0.5}
Hi @shumwayn, you mention that the model ran for 18 hours and completed … is the model run still failing on a different set of inputs or something? If not, I’m happy to just call this resolved
So the model ran for over 30 hours and created all of the raster outputs but didn’t create the final shapefile. Previously when the model has run and it gives an error, it remains on the log file and I can see the error in red. This time the program actually closed, so it’s unclear to me what the error was. I tried to send the log file but it’s too big- do you have another way I could send it?
It may have been a space issue- I only had 600 mb left on my computer, so I am hoping there is some way to create the final watershed_sdr shapefile without having to run it for 30 hours again?
Yes, InVEST will typically crash if it gets close to running out of disk space, but the sort of crash you’re describing is quite severe and not something we’d generally expect.
Could you send the logfile via dropbox, google drive or some other file sharing service?
Regarding the 30-hour runtime, if you re-run the model on the same workspace (without deleting the files in the workspace), the model should resume where it left off.
Interesting! That’s not an error that I would expect at that point in the model. Could you try this latest development build of InVEST and see if that resolves this issue?
I am using Invest SDR 3.7- I installed the latest version a couple of weeks ago when I first started using it and troubleshooting. Have there been recent changes since then?
Thanks for all of your help so far, it’s been great. So the SDR model has been running for about 170 hours. It made all of the raster outputs after about 3 days but has still been working on the shapefile; however, I got this error this morning (see attached log). Not sure what the problem is but any help would be greatly appreciated. Happy Thanksgiving!! (2.2 MB)
Hi James, haha - yes, it was super long. I think it will probably be easier to run until we get the rasters and then create the shapefiles ourselves. I’ve got it running on two different servers to speed things up. I’ve attached the log here - its one of these two. Thanks!
OK! The error near the end looks especially interesting here:
Traceback (most recent call last):
File "Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\taskgraph\Task.py", line 602, in add_task
File "Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\taskgraph\Task.py", line 1068, in _call
File "Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\natcap\invest\sdr.py", line 1123, in _generate_report
File "Z:\opt\atlassian\pipelines\agent\build\env\lib\site-packages\pygeoprocessing\geoprocessing.py", line 1151, in zonal_statistics
RuntimeError: Could not open aggregate vector at D:/Users/uqnshumw/Desktop/OneDrive - The University of Queensland/Documents/ArcGIS_NEW/Coral_mining Project/Coral_Mining Analysis/InVEST/InVEST/watersheds.shp
The most important thing is the error itself, that the aggregate vector could not be opened. It looks like your watersheds file might be located within a OneDrive folder … is that the case? If so, I’d suggest re-running the model with your aggregate vector stored outside any file-synchronization service. Services like Dropbox, OneDrive, Google Drive and others will periodically open all of the files within their directories to scan for changes. While the file is being examined by these programs, InVEST won’t be able to open the file.
Another possibility is that some other program has the vector open. Common culprits in this case would be ArcGIS and/or QGIS.
The good news here is that once the watersheds issue is resolved, you should be able to re-run the model just with the new input and so long as the workspace stays the same, the model should pick up where it left off.
(344.6 KB) 
(2.2 MB)