Skip to the navigation links
Last modified: 28 December 2009

URL: http://cxc-newtest.cfa.harvard.edu/ciao4.2/bugs/csmooth.html

Bugs: csmooth


Bugs

  1. There is a bug in the logic of csmooth that may cause the tool to hang near the 99.5% completion mark, then slowly creep towards max kernel size.

  2. Problem in algorithm includes background doubling in the smoothed region which is ONLY an issue with very high background data.


Bugs

  1. There is a bug in the logic of csmooth that may cause the tool to hang near the 99.5% completion mark, then slowly creep towards max kernel size.

    If the tool appears to be running for a long time on a particular dataset, try setting verbose > 0. It may be getting stuck on a particular kernel size (or only asymptotically approaching the maximum kernel), as shown here:

                       smoothing  out/in       pixels    counts     significance  
     n_max  m_krnl_min  radius    diffl  cumul  done (%)  done (%)      range  
                                                                    min   med   max   
    ---------------------------------------------------------------------------------
    ....
    
      8.00     10.35    36.663    1.000  1.000   53.12     97.44    3.00  3.89  9.87
      8.00     13.47    36.673    1.000  1.000   54.35     99.42    3.00  5.29 34.67
      4.00     12.47    36.683    1.000  1.000   54.77     99.52    3.00  3.49 11.73
      2.00  14211.30    37.351    1.000  1.000   54.77     99.53   11.59 11.59 11.59
      1.00  13920.84    37.685    1.000  1.000   54.77     99.53    3.20  3.20  3.20
      3.00  14215.57    38.019    1.000  1.000   54.77     99.53    3.28  3.97 14.99
    .....
    

    Notice that the kernel size explodes to 14211.30 (from 12.47); at this point, something in the statistics/guessing/etc. goes awry, and the 99.53% complete takes forever to finish. Note that when running with verbose > 0, csmooth actually has to compute all those statistics. If you do not need them, set verbose = 0 and the tool will finish more quickly.

    Workaround:

    There is no fail-safe workaround, but there are a few changes to make if you are affected by this bug:

    • csmooth work best with images that have 2n axes. Either clip or pad the image to change the axes.

    • Try changing the parameter defaults, especially for the sclmax and/or the sigmin/sigmax. These choices can significantly affect the run-time (both negatively and positively). The bigger the range between sigmin and sigmax, the fewer scales will be run.

      Actually, one of the main reasons csmooth runs slowly is that many users leave sclmax = INDEF, in which case it has to try to get the last few/partial %'s by increasing the cell size. Choose a reasonable value for this parameter and the tool won't waste a lot of time smoothing at very large scales. For the above example, sclmax = 37 would be a good starting point.

    • Crop image to data-size so there is always some background. This does have the caveat that FFT convolutions do suffer from edge effects that are usually mitigated by padding (and while slide-convolve is an option, it's very slow). But if the interesting part of the image is in the center, edge effect are less of an issue.

  2. Problem in algorithm includes background doubling in the smoothed region which is ONLY an issue with very high background data.

    An example of a high background is 50 counts per pixel.


Last modified: 28 December 2009