quickly offhand, don't use arr as the variable name for output since it 'exists' try arr_out ... I will check when on an arc machine
BACK
I just assembled a test using 3 arrays (floating point) and stacked them
Dan demos in python 3.4
Date...
>>> a_rc
array([[ 7., 6., 8., ..., 8., 7., 7.],
[ 7., 7., 7., ..., 8., 7., 8.],
[ 7., 7., 8., ..., 8., 7., 7.],
...,
[ 8., 8., 7., ..., 8., 4., 6.],
[ 8., 7., 7., ..., 7., 7., 8.],
[ 2., 1., 8., ..., 8., 3., 8.]])
>>> t = np.vstack((a_rc,a_rc,a_rc))
>>> t
array([[ 7., 6., 8., ..., 8., 7., 7.],
[ 7., 7., 7., ..., 8., 7., 8.],
[ 7., 7., 8., ..., 8., 7., 7.],
...,
[ 8., 8., 7., ..., 8., 4., 6.],
[ 8., 7., 7., ..., 7., 7., 8.],
[ 2., 1., 8., ..., 8., 3., 8.]])
>>>
>>> import arcpy
>>> tt = arcpy.NumPyArrayToRaster(t)
>>> tt.save("f:/test/tt")
>>> t.ndim
2
>>> t.shape
(21000, 14000)
>>>The results
Do note the size of the input arrays and the output raster. I am just praying that the inability to save was due to the naming convention and that you don't have to save each raster, then
Mosaic To New Raster—Help | ArcGIS for Desktop . If it is a memory issue you will have to label the LL corner of each array, save it so that they can be merged inside of arcmap into a final array.
Rebecca... time to move to python 3.4 (at least) 
Dan, I don't think the "arr" name itself the issue (since that made no difference), but I'm using a different array names just in case.
What I am doing now is redefining each array as "= []" as soon as I don't need it anymore, which seems to free up the space. From a number of other discussions I've read thru, doing a "del array_variable" only deletes the variable and does not free up the memory. (just an fyi for anyone reading this). So that help.
The next issues (not discovered or resolved in this order) were that I had to specify the lowerleft and the cell-size that I saved at the very beginning of my script from the original raster....I also had to use DefineProjection since that isn't an option in the NumPyArrayToRaster (snippet of these lines below)
np.save(r"C:\___bear2016\_Skwentna2017\outras.npy", arr) #save in binary format arr = [] arrLoad = np.load(r"C:\___bear2016\_Skwentna2017\outras.npy") # count number of elements so it can be split arrCnt = len(arrLoad) arrSplit0 = int(arrCnt/3) arrSplit1 = (int(arrCnt/3) * 2) # now reclass in slices and stack back arr_rc0 = arr_reclass(arrLoad[:arrSplit0,:], bins=bins, new_bins=new_bins) arr_rc1 = arr_reclass(arrLoad[arrSplit0:arrSplit1,:], bins=bins, new_bins=new_bins) arr_rc2 = arr_reclass(arrLoad[arrSplit1:,:], bins=bins, new_bins=new_bins) arr_stack = np.vstack((arr_rc0,arr_rc1, arr_rc2)) print(arr_stack.ndim) print(arr_stack.shape) arr_rc0 = [] arr_rc1 = [] arr_rc2 = [] print(lowerLeft) newRas = arcpy.NumPyArrayToRaster(arr_stack, lowerLeft, cellSize) newRas.save(outDEMtmp) newRas = [] arcpy.DefineProjection_management(outDEMtmp, spatialref) arcpy.RasterToPolygon_conversion(outDEMtmp, pElevClass, "SIMPLIFY", "Value")
So, now the issue is that the RasterToPolygon does not see the outDEMtmp as a valid raster,
even though it appears to be fine when displaying and/or looking at the properties.
the error in the python window (which I tried first)
>>> arcpy.RasterToPolygon_conversion(outDEMtmp, pElevClass, "SIMPLIFY", "Value")
Runtime error Traceback (most recent call last): File "<string>", line 1, in <module> File "c:\program files (x86)\arcgis\desktop10.3\arcpy\arcpy\conversion.py", line 337, in RasterToPolygon raise e ExecuteError: ERROR 000864: Input raster: The input is not within the defined domain. ERROR 000367: Invalid GP data type
>>>
Neither of the error seems to be relevant. A restart didn't help....so on to researching this. ...maybe I'll copy to a new raster, if that works. Any chance the NumPyToRaster doesn't work quite right??
