Spitzer Documentation & Tools
IRS Instrument Handbook

See also Section 7.2.2.

7.2  All Spectral Modules

7.2.1             Saturated Data

Please see Section 7.1.1.

7.2.2             Rogue Pixels and NaNs

Rogue pixels are warm/unstable pixels. Early in the mission, all four IRS arrays were subjected to powerful solar proton events that deposited the equivalent dose of protons expected over 2.5 years in only two days. This damaged 1% of the SL and SH pixels, and 4% of the LL and LH pixels. See also Section 7.1.3. The greatest science impact is to the LH module because the illuminated portion of the orders subtends only a few pixels in the spatial direction, making it more difficult to recover lost information by nodding the source along the slit. As the Spitzer cold mission progressed, the number of rogues and permanently damaged pixels increased. The bias for LH was lowered in IRS Campaign 25 in order to slow down the rate of rogue production at the expense of a decrease in sensitivity.  Similarly, the bias and temperature were changed for LL in Campaign 45.

The damaged pixels are masked from data processing by assigning NaN status to them.  This prevents numerical operations from being affected by their presence.  Assigning any other real number would lead to improper processing of the surrounding signal information, such as during the extraction process.  By default, the post-BCD EXTRACT module (see Section 5.7.3) interpolates over the NaN pixels when adding flux within an aperture.  The affected pixels are marked in the corresponding pmask and bmask.

Occasionally, it is possible for rogue pixels to propagate through the pipeline without being flagged as NaNs. In this case, these spurious pixel values will be extracted and appear as sharp spikes in the final spectrum. Such features should be readily recognizable as spectral features which are too sharp to be real.  The IRSCLEAN_MASK package enables observers to visually inspect such pixels and interpolate over them. If there is any doubt about the reality of a given spectral feature seen in an extracted spectrum, we recommend that the observer always examine the 2D BCD images to cofirm that the feature shows the expected spatial and spectral dispersion on the array.

7.2.3             Radhits on rogue pixels

Low and high resolution spectra may show large spikes when cosmic radiation hits (radhits) fall on highly-nonlinear (rogue) pixels. This effect is made more evident by the pipeline's (S15 and onward) rejection of samples following a radhit event. The early samples in nonlinear (rogue) pixels generally have a steeper slope than the samples rejected after the radhit, increasing the flux after radhit rejection.

Rogue pixel data have incorrect values and should generally be filtered out before or during spectral extraction. Two methods can be used to remove the offending pixels:

   1. Use SPICE to re-extract the spectrum (using bcd.fits files as a starting point). Within SPICE you can use the EXTRACT 'Mask' pulldown menu to mark bit #3. This will cause SPICE to ignore pixels with radhits. Then run EXTRACT.

   2. Use the IRSCLEAN_MASK routine to filter and replace the offending pixels.

7.2.4             Severe Jailbars

Very strong vertical stripes (jailbars) are sometimes seen in a single BCD image of an AOR. This may lead to very noisy or corrupted spectra.

A few rows of data in one plane of the corresponding cube will be seen to have anomalously high values (can be several tens of thousands of DN). These rows are not tagged as missing data, and in cubes of 4 samples, they are not recognized as outliers. Even before slope estimation, these rows affect the entire array because droop is impacted for all pixels of that plane, leading to severe jailbars.

The severe jailbars discussed here occur very infrequently (~1/700 DCEs). The root cause of the corrupted rows in the cube leading to severe jailbars is unknown. More mild jailbars may observed as a result of other causes.

There is currently no fix for this problem in the pipeline. It would have to be fixed at the raw datacube level. If multiple DCEs are available, throw out the offending DCE and recompute the spectrum.

7.2.5             Latent Charge

Despite the resetting of the detector after every integration, a small fraction of charge on the detector persists between frames. This latent charge is thought to be small, (~1−2% of the charge on the pixels) and decays slowly over time. It is removed by the annealing process which occurs every three to four days of an IRS campaign.

In the case of very faint sources, the source of latent charge is the zodiacal background. This charge can build up to significant levels over long integrations, sometimes as much as 30−50% of the true background in ~4 hour integrations. The slope of the latent build up is a function of wavelength and sky background but does not appear to be constant from AOR to AOR.  The latent signal can be removed by fitting the slope of the background in each row (i.e. wavelength) as a function of frame number and subtracting that amount row-by-row from each frame. The slope can be fit by 1D or 2D polynomials and the fits should be visually checked to ensure that anomalous values for the sky have not been obtained. Figure 7.1 shows an example of the charge build-up in a long integration in a field with low (~18 MJy/sr) background as well as a 2D polynomial fit which was removed from each BCD at each wavelength.

This effect should not be confused with the build up of charge and stabilization of signal discussed in Grillmair et al. (2007, ApJ 658, L115), when observations of a bright source are undertaken.

Figure 7.1:  Latent charge build-up in electron/s on the LL array in a long (120 s) integration.