The following document is intended to provide pre-flight guidelines for Q/A checking the pipeline data products. I note that at this time these guidelines are deliberately quite vague - they cannot be more completely realized until after the IST has acquired experience with the in-flight performance characteristics of IRAC. Note that 5,6, and 8 (especially 8) could indicate possible real problems with IRAC, and should probably be brought to the attention of the IRAC-IST.

Some discretion is required on the part of the Q/A team, but I assume they will know what the target was meant to be. Obviously, for blank-field surveys this won't work, but most observations will be pointed at a target. It should be pretty obvious if something is there. If something appears to be visible, it should ideally have a peak intensity at least 5x the background, and ideally about half full-well. Unfortunately, the well-depth is best measured in DN, but the mosaics will be in MJy/sr, so I will have to figure out what that is likely to be for each exposure time.

This may sound dumb, but there were significant problem with HST and bad pointing early on. I also anticipate users inexperienced in the IR, who don't calculate sensitivities and brightnesses correctly.

Again discretion is need, but if more than 10% of the pixels are tagged as saturated, then there was probably a problem with the chosen exposure times. This is particularly likely to happen with channel 4, which has a high celestial background. The one exception is if the data was taken in HDR mode. In this case, just look for saturation in the shortest frame. If you are just looking at the post-BCD mosaics, then HDR mode is automatically handled, and the saturated pixels should have been replaced.

IRAC data dropouts look like sets of 4 missing rows in the images, and can be immediately detected by the missing data flag in the header being set to true. If the total amount of missing data exceeds 2%, then this should be flagged as a problem.

There are two aspect to this:

Relative pointing - IRAC frames have their coordinates aligned with each other in the pipeline. An error in this stage will cause "doubled" (or distorted) objects in the overlap regions of the mosaiced data.

Absolute pointing - IRAC frames also have their pointing aligned using 2MASS as an absolute reference. This can be easily checked using an overlay of 2MASS sources on top of the mosaic. There is supposed to be such a catalog supplied as part of the post-BCD processing, as it used by the pointing refinement module.

The BCD headers will contain an estimate of the background level in MJy/sr, or you can get it yourself from Bill Reach's model. The background level should match the model to within 50%.

Was there an error in how the darks and flat were applied to the individual DCEs? This will manifest itself in the mosaic as an apparent cross-hatching or wiggle in the background level. In all likelihood it will be more or less periodic. It would take a detailed look at the pipeline intermediate products to decide which it was. Basically, one would examine the post-FLATAP and post-DARKSUB products to see where the error was made.

IRAC has stray light issues caused by glints off structures near the array mounts. This will look like a "ray" of light (probably emanating from nothing obvious) about 100 pixels long and 10s of pixels wide. It generally comes from an array corner.

The IST can supply you with an example of what a radial profile of a point source should look like in each band. Two or three should be spot-checked in the mosaic to make sure they match this. It should be easy to make a tool that does this. This could be caused by either a focus change in IRAC, or a pointing reconstruction error. A check of an individual image would show this immediately, as a real focus change will show up in the BCD, but a pointing error causing a fattening of the PSF will not. An actual focus change in IRAC is a very serious problem, and should immediately be forwarded to the IST for further investigation!