AnsweredAssumed Answered

"python.exe has stopped working" on raster.save

Question asked by amilt on Apr 3, 2013
Latest reply on Jun 19, 2013 by forreststevens
I am attempting to perform raster calculations with in-memory rasters in a script using arcpy (ArcMap v10.0). I get this error from multiple different inputs and it occurs from multiple different areas in my code depending on slight modifications.

The basic workflow is this:

  • load in a raster using arcpy.sa.Raster

  • perform a raster calculation

  • save the raster using raster.save (this is where the error occurs)


For example, I have

# make a raster from the bounding region result = arcpy.PolygonToRaster_conversion(boundingRegion, vField, outputRegion, '', '', cellSize) outputRaster = arcpy.sa.Raster(outputRegion) outputRaster.save('C:/temp/temprast.tif') # no error occurs          # convert any NoData to "outside" the output region outputRaster = arcpy.sa.Con(arcpy.sa.IsNull(outputRaster), rastOutVal, rastInVal) outputRaster.save('C:/temp/temprast.tif') # python crashes with a pop-up window and windows error "python.exe has stopped working"


Sometimes saving the raster has no ill effect. And saving the raster to a different filename (e.g. C:/temp/temprast2.tif) for consecutive calculations also averts the crash. However, the crash that I am concerned about happens when I attempt to save the raster only once and do so at the end of several raster calculations.

I have a couple guesses as to what may be causing the crash.

1) arcpy attempts to write the file before the raster calculation is complete. I dont think this is the case. I have put in a sleep command for 10 seconds, which should be plenty of time. Arcpy would also have to be creating a sub-process that can run behind the main process, which I dont think is happening.

2) arcpy attempts to save a raster with no information or incompatible information that has been produced during calculations. I dont think this is the case, because I can get an output file saved if I save all the intermediate rasters to files before the final one. So unless writing each intermediate raster to a file somehow makes the information compatible with future calculations, this cant be it.

3) In attempting to save the in-memory raster to the hard drive, arcpy is attempting to access/overwrite the same RAM that is currently occupied by the in-memory raster. I dont have a way to test this.

Any suggestions would be a huge help. One boon of arcpy in v10.x is the ability to perform raster calculations in-memory. The only solution I can come up with (save all intermediate rasters as separate files) takes away this advantage.

I've attached a sub-section of the problem script. I cant attach the whole thing because it is part of a package I hope to release in the near future.

UPDATE: I have just discovered another curious way to avoid the problem I was having.
1) If I put in a breakpoint (import pdb; pdb.set_trace) just before the spot where the final raster is to be saved to disk, and
2) then call a different temporary raster that is stored in memory (i.e. >> raster), and finally
3) call the output raster (i.e. >> outputRaster)

then the problem does not happen. The mechanism that seems to be at work here is that when the temporary rasters are accessed in Python (by me), they are written to the hard disk (confirmed by watching files in the temporary directory). This subsequently means all arcpy has to do when the outputRaster.save command is called is change the name/copy the temporary raster to its permanent location.

However, this does not solve my problem! If I try something like ">> print raster" without the break statement, I get the same crash. For some reason I need to be interactively calling the rasters for them to be written to the hard disk.

It also appears the the output raster is wrong with this method.

Hopefully it gives some additional helpful information.

UPDATE 2: Doing the same thing in UPDATE 1, but putting the breakpoint at the beginning of the raster calculations seems to solve the problem of the output being false. I guess there's an issue with raster calculations in memory.

Attachments

Outcomes