Commits
CAS-14184 : Fix peakres calculation
Added a check for masksum while calculating peakres across a cube. Only in the case that masksum > 0 is peakres considered now. This prevents the "bouncing" behaviour reported by Josh described below: Iteration 1 : field 0, chan 0, stokes 0, peakres [1.0149141550064087] field 0, chan 1, stokes 0, peakres [5.736467361450195] field 0, chan 2, stokes 0, peakres [4.154384136199951] cyclethreshold = 1.0222507446548832 Above the cycle threshold is determined by the global peak value (5.736) and chan 0 is cleaned down until the threshold. It returns to the GUI and we click again, nothing happens because we are in convergence. But peakres still gets updated as below. Iteration 2 (after convergence) field 0, chan 0, stokes 0, peakres [1.0149141550064087, 1.014911413192749] field 0, chan 1, stokes 0, peakres [5.736467361450195, -0.0] field 0, chan 2, stokes 0, peakres [4.154384136199951, 0.0] cyclethreshold=0.18085938305290838 Here we have hit convergence, we take the niter=0 path in deconvolve and set peakres=0 for channels with no mask. Now cyclethreshold is determined by the residual in the first channel, and drops. But since we are in the niter=0 path no deconvolution happens. Iteration 3 : field 0, chan 0, stokes 0, peakres [1.0149141550064087, 1.014911413192749, 0.6902092099189758] field 0, chan 1, stokes 0, peakres [5.736467361450195, -0.0, 5.736467361450195] field 0, chan 2, stokes 0, peakres [4.154384136199951, 0.0, 4.154384136199951] cyclethreshold = 1.0222507446548832 We end up doing more deconvolution based on the previous cyclethreshold, and now once again the new cyclethreshold is determined by the global peak (5.736) and is too high to continue deconvolution.