| | 7 | |
| | 8 | I've been splitting my time this week on three areas: extended sources, image subtraction, and dvo database issues. For extended sources, I have concluded that the current psf-convolved fitting is working fine, but it is too slow for practical work. There are a couple of things that I can do to speed it up substantially: convert the convolution to use FFTs and add in threading. Both are fairly straight-forward given the rest of the IPP code. |
| | 9 | |
| | 10 | Meanwhile, I have been looking at cases where the warp-warp subtractions are resulting in high numbers of false positives in an attempt to either characterize the false positives and/or to reduce them up front. Towards the first goal, I have added the ability to associate the diff detections with the nearest positive source above some S/N limit in both of the input images. I've added 5 new fields to the output cmf files: the S/N and distance to the source in the positive image (relative to the diff detection) and the same for the negative image, and a new set of flags, including bits the identify that a diff source is matched to a positive image source. |
| | 11 | |
| | 12 | In terms of reducing the false positives, a major contributor seems to come from times when the image quality difference is large (eg, a sub-arcsecond image and one with 1.6 arcsec FWHM). It seems that at least 2 bad things are happening in ppSub in these cases (and maybe to some extent in less extreme cases): 1) the FWHM-based kernel scaling code saturates at one of the extremes, and 2) the normalization is poorly measured. I suspect (2) is more of a problem than (1), but both are a concern. I am looking into improving the robustness of the normalization measurement. |
| | 13 | |
| | 14 | On DVO related issues: I have tested the updated dvomerge code -- I reworked the processing order so that only the new database is completely loaded rather than the output database -- and find that it have a much improved performance. It now runs at a rate that is essentially linear in the size of the input database (ie, the incoming mini database). It is still a bit slower than I might want: it runs at a rate equivalent to about 5-10 MByte per second, so it is clearly not I/O limited. It is single threaded, but it would not be difficult to change to a multi-threaded option (one thread per merged database sky region). |
