Bugs: csmooth

Caveats

1. When working with extended sources, the background should be supplied in an external file, not computed from the input 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.

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

Caveats

1. When working with extended sources, the background should be supplied in an external file, not computed from the input data.

   The background is calculated from the region surrounding the smoothing kernel when using the "local" option (bkgmode parameter). Working with extended sources in this mode causes csmooth to use the extended emission of the source as the background in the calculation of the significance map, and the smoothed image will not be correct.

   Users should be extremely cautious when using a background option in csmooth while working with extended sources (and diffuse emission). The user should always go back to the un-smoothed data and determine if the results of the smoothing seem reasonable.

   Three parameters are used to specify the background file:

   • bkgmode = "user"
   • bkgmap = background image file
   • bkgerr = background error image file

   Note that the image must be of the same dimensions as the data, and is assumed to be in the same units. The ACIS Background file thread shows how to create a background file for your data.

   For pointlike objects the surrounding background is close to the true background, so the "local" mode works much better than it does for extended sources.

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 2ⁿ 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.