Bugs: wavdetect

wavdetect creates several temporary files. If it is terminated (Control+C) or otherwise quits unexpected, it not delete those temporary files. The next time you run wavdetect it may then report an error similar to above about "Bad file name in ... stack ....".

This may also happen if multiple instances of wavdetect are run on the same computer at the same time without changing the interdir and/or outputinfix parameter to unique names for each instance.

Workaround:

/bin/rm ${ASCDS_WORK_PATH}/wr*stk ${ASCDS_WORK_PATH}/wt*stk ${ASCDS_WORK_PATH}/wd*stk

The RA_ERR and DEC_ERR values are approximations and become increasing inaccurate the closer to the poles, DEC=+/-90.

Users may also see incorrect values for these errors for RA values very near 0|360 such that the error bar crosses the boundary and wraps around.

Workaround:

The X_ERR and Y_ERR values in physical pixels is correct. Users can use these together with the known plate scale to compute their own error estimates.

Multiple instances of wavdetect cannot reliably be run at the same time on the same computer with the default parameter settings. Beyond needing to change the PFILES environment variable, wavdetect also creates many temporary files (and lists of files) that need to be kept separate. These files are not locked and may get overwritten or clobbered by jobs running in parallel on the same machine.

Workaround:

Users should set the ASCDS_WORK_PATH environment variable before running wavdetect to a separate, unique location for each instance of wavdetect that is being run.

(ba)sh: export ASCDS_WORK_PATH=$PWD/tmpdir_A
(t)csh: setenv ASCDS_WORK_PATH $PWD/tmpdir_A

The radius, "R" column, in the output source list is computed as the standard deviation of the source pixels along the semi-major and semi-minor axes. If the pixels that make up a source are aligned along a single X column or Y row or it is simply a delta function (single pixel) then the standard deviation is 0. A small value, based on the image blocking, is used in this case to provide some visual indication of the sources existence.

For a source to be considered real, it must be found to be significant when it is smoothed at a wavelet scale larger than the PSF. Consider two sources: one with 5 counts and one with 100 counts, each in a single pixel. It will take only a small wavelet scale to smooth out the 5 counts before it would no longer be considered significant whereas it would take a much larger wavelet scale to smooth out the 100 counts before it would no longer be considered significant. In either case, the source ellipse is based on the smallest wavelet scale it was found to be significant (whether that scale is smaller than the PSF or not). This ensure that the best source position is returned and allows close pairs to be identified.

The input wavelet scales are independent, orthogonal basis functions that describe the local structure on the scale of each wavelet. Within a single wavelet scale, sources must not overlap but since each wavelet scale represents an independent spatial scale, the same pixels can contribute to multiple sources. This is the very nature of a wavelet decomposition. (The Fourier analog is that all pixels contribute at each frequency.) The output cell image, whose pixel values represent which source a pixel "belongs to", cannot truly capture this and only represents the last (usually largest) wavelet scale.

Wavdetect is not a photometric tool; it is a source detection tool. The derived properties including location, counts, and sizes are provisional estimates. Users must perform full analysis on sources to determine reliable results.

wavdetect only knows how to convert a PSF map in arcsec units to logical pixel size to match the input image. All other units are ignored and the PSF map is treated as having logical pixel size values.

If the PSF map was created with physical pixel size values, and the image was binned by any value other than 1, then the PSF map values will not be correctly converted to match the input image. This may result in a different set of source detections and|or may result in the properties of those sources, including the radii, being wrong.

Users can check the units of the PSF map pixel values using dmlist, such as

unix% dmlist mypsfmap.fits cols
--------------------------------------------------------------------------------
Columns for Image Block broad.psfmap
--------------------------------------------------------------------------------
 
ColNo  Name                 Unit        Type             Range
   1   mypsfmap.fits[2613,3222] logical      Real4(2613x3222) -Inf:+Inf            
...

This example shows a PSF map with units of logical pixel size.

In general, autonaming only works for simple cases.

The output PSF_SIZE and PSFRATIO columns may contain a value of NaN even for sources with otherwise valid properties (eg position).