Maximum Iterations for Solution Convergence - Limit reached!

[rafaelruas]

I'm running the UDef-ARP package to facilitate the deployment of VT0007 and I'm having problems.

Specifically, in Testing Phase, Prediction Phase (CNF), step 2 Allocated Risk Mapping, the Maximum Iterations For Solution Convergence parameter is always reaching the limit. I've scaled the parameter up to 10,000 iterations, for example, and I keep getting the limit reached warning. I've retraced all the steps up to this stage (without any problems, warnings or errors) and I can't understand what could be wrong. My data is of 30m spatial resolution, all binary maps is 1 and 0, coord. system the same, number of pixels the sam.

Any suggestions on what to check to overcome this problem?

[YaoTingYao]

Hi @rafaelruas, we recently fixed an issue related to iteration limits in #34. Could you confirm if you are using the latest version of the code with this fix? If you're still encountering the problem, please share the dataset you used for Step 2 (CNF) so we can conduct further testing. Cheers!

[rafaelruas]

Hi YaoTingYao. Thanks for your answer. I downloaded the code in september 29. Probabily the latest version, isn´t it? I am shareing my data and some explanation obout it for you try to understand what is going on. HELP.zip Andrew, from Verra, helped me. However, something is strange. He processed my data w/ success and shared w/ me one of the binary data needed to run the tool correctly. However, his binary map covers the entire EXTENT of the map, and mine only where there is data (within the jurisdiction). Another difference is that ArcGIS Pro (the tool I'm using) is assigning the value 3 to NoData in the file's properties (in its metadata, perhaps). Even when I look at the properties of his file, the same thing happens: it assigns the value 3 to NoData. Similarly, it assigned the value 15 to my land use raster whose pixels contained values of 1, 2, 3, and 4.

Shared files: My binary data (Def_in_CNF_2.tif) and the Andrew´s product of the "same geoprocessing" (conf_deforestation_agc.tif) and the inputs (land use/cover maps: 1-forest, 4-deforest) to create those binary maps.

The script I'm using to generate the deforestation map (the binary one) is this one as follow:

---

import arcpy

Input rasters

T2 = "C:/SIG/UDEF_ARP/INPUTS/DesmatAcum_2015.tif" T3 = "C:/SIG/UDEF_ARP/INPUTS/DesmatAcum_2020.tif"

Output raster

output_raster = "C:/SIG/UDEF_ARP/INPUTS/Def_in_CNF.tif"

Envir. configs

arcpy.env.extent = T2 arcpy.env.snapRaster = T2

Conditional

mask = arcpy.sa.Con((arcpy.Raster(T3) == 4) & (arcpy.Raster(T2) == 1), 1, 0)

Save output raster

mask.save(output_raster)

Message

print("Processo concluído! O raster binário foi salvo em: {}".format(output_raster))

---

Do you notice anything I'm doing wrong in terms of generation the binary deforestation data?

[YaoTingYao]

Hi @rafaelruas, yes, the code downloaded on September 29 does include PR #34. The issue you're experiencing with the AR value happens because, during the image-to-array conversion, the nodata value gets value 3. This leads to an extremely high AR value, which is causing the iteration issue you mentioned. Please try using the binary data processed by Verra. It appears to handle the AR value correctly, as areas without deforestation are consistently represented by 0, rather than nodata values being converted to 3.

[agcopenhaver]

Hi @rafaelruas, as @YaoTingYao has noted, this is not an issue with the tool. You should be able to set your nodata value in arcpy's data management toolbox, although I am admittedly unfamiliar with arcpy at this point.

However, your issue is noted and I will add it to the backlog of future improvements. Similarly, feel free to submit a pull request if you develop a fix yourself.