FPACKing exonerated as Bugs in swarp and ImageProc Corrupts Modeling

-Eli Rykoff

This is a very important update to FPACKing the Weight Maps Corrupts Coadd Modeling that shows that the FPACK issue was a red herring. The actual problem is a bug in swarp triggered by a bug in ImageProc.

The Problem

Please see Y1C1 Stellar and Galaxy Modeling Issues and Y1C2 Stellar and Galaxy Modeling Issues and FPACKing the Weight Maps Corrupts Coadd Modeling for details. The basic problem is that on both the Y1C1 and Y1C2 coadds the DETMODEL zeropoints (relative to aperture magnitudes) are all over the place. What's up with that?

Note that although the DETMODEL zeropoint shifts (sometimes over 10%) are the most obvious manifestation of this issue, I assume that there may be other problems lurking at a lower level.

The FPACK association

In the previous tests, I had tracked down so that I could replicate the bug by running fpack/funpack on the weight maps on the swarp-remapped images. However, as I noted, I could neither see any obvious corruption in the funpacked weight maps (even after fixing the 0 bug), nor did I have a plausible mechanism for how this could trigger the photometry bugs.

Running Swarp in Two Stages

When constructing a test-suite for Emmanuel, I realized that there was one other change from my regular to fpack test runs. In my regular runs, I ran swarp once, to do both image remapping (RESAMPLE Y) and coaddition (COMBINE Y). However, in the fpack runs I ran twice, once for image remapping (RESAMPLE Y, COMBINE N) and once for coaddition (RESAMPLE N, COMBINE Y).

It turns out that this was the problem that was triggering the photometry bug. When swarp is run with resampled images as the input for pure coaddition (as is done in the pipeline), the output grid is computed slightly differently. Depending on where the central ra/dec is with respect to the pixel grid, then (in swarp 2.36.0 and earlier) floating point rounding can shift the entire image by +/-1 pixel in either or both X or Y, even though the output WCS coordinates are the same. This is a very subtle shift but is obvious if you run the coaddition both ways and blink the images in DS9 matching the physical pixels. (Since the WCS coordinates are correct for the new pixel grid, matching to WCS will not show this shift).

And as it happens, if you shift the detection and measurement image by +/-1 pixels, then the DETMODEL photometry, which relies on the two images being on the same pixel grid, will be messed up. I'm assuming the other colors, especially smaller aperture colors, will also be affected though apparently at a lower level.

So this is the source of our problems, and (unlike the fpack correlation), we now have a transmission mechanism rather than a spurious correlation. Hooray!

Fixing Swarp: Please Upgrade to 2.36.1 (or later)!

I have contacted Emmanuel about this bug, and he has very quickly identified an issue with the rounding of CRPIX values when resampled images were used as input. This new version (2.36.1) fixes the rounding shift on two test images. I am currently running a much larger suite of images.

Using Survey Tile Headers to Avoid This Problem

In the survey mode, we split apart the remapping and coaddition into different stages for many reasons, and we also run the different bands at different times with (obviously) different input images. As Emmanuel has reminded me, to avoid any ambiguity swarp can also take in a survey tile header to unambiguously define the output grid (rather than rely on computing the grid from command line parameters).

It is my impression that we are set up to use standard survey tile headers in ImageProc. And looking at the remap log files, we use in the remapped tile header, e.g., tileheadfile=DES0410-4957.desremap.head, which is used by swarp. (One thing I am not clear on is where this header file is defined or how it gets put in place.)

However, this remap header is not used in the coaddition. Looking at a coadd_swarp log file, which is where the second stage of swarp is run (RESAMPLE N, COMBINE Y) there is no reference to the tileheadfile. This needs to be added to ensure that all images from the same tile are put on an identical pixel grid.