Nod Flux oversubtraction correction for NIRSpec Fixed-Slit and MOS point-source spectra

[stscijgbot-jp]

Issue JP-3647 was created on JIRA by Charles Proffitt:

When background subtraction is done in the NIRSpec FS or MOS mode using in-scene dithers (nods), some fraction of the source flux is subtracted along with the real sky background.  This fraction will vary with wavelength, the spatial offsets of the individual background exposures from the science exposure, the physical slit used, and the size of the extraction box used.  

As a result, with the current pipeline calibration strategy, the extracted flux reported for a given source can vary significantly depending on the dither pattern used.  For example, when doing a standard 3 point dither in the S1600A1, for a bright source where the real sky background is negligible, using the pixel-by-pixel background subtraction gives fluxes about 3.5% to 6% lower than when no background subtraction is performed.  Likewise, cases where an observation uses a dedicated background pointing will have fluxes inconsistent with the flux derived for the same source observed with in-scene dithers.  We would like to implement a flux correction step which reduces the inconsistencies between the different background strategies to less than 1%. 

This correction step will need a reference file that the NIRSpec team will deliver that gives the fraction of the source flux contaminating the background measurements as a function of wavelength and the spatial offset between the science and background members. A different table will be needed for each fixed-slit aperture and each allowed extraction box height. However, currently the NIRSpec pipeline is only set up to support a single extraction box height for each fixed-slit or MOS aperture. In principle these table might also depend on grating and/or filter. If this correction step is added it will also the F-Flats to be updated.

The correction depends both on the dither offsets used in the background subtraction, and the size of the extraction box used by Extract1D.  The most logical places to apply this correction may be either 1) during nod subtraction in spec2 when there is access to the spatial offsets of each dither or 2) 1D extraction, where the extraction width will be defined.  Option 1) would require assuming a specific extraction box size as is currently done for F-Flats, whereas option 2) would require recording the spatial offsets of all background dithers in the slit metadata, and may have some complications for how to combine the corrections for multiple spectra in spec3.

[stscijgbot-jp]

Comment by Greg Sloan on JIRA:

MIRI LRS sees this effect as well for spectra in the slit, but it's only 2-3%, and only at longer wavelengths where the PSFs are large enough for the wings to overlap. Because the nod-along-the-slit dither is standard for observing a point source in the LRS slit and because the needed correction is a simple multiplicative vector, it's already built into the photom correction. The issue for the LRS slit will be for non-standard observations, primarily those observed in the slit center and using a separate background pointing.

[stscijgbot-jp]

Comment by Melanie Clarke on JIRA:

Charles Proffitt - The option to correct the flux at the nod subtraction stage seems most logical to me, since that's when the effect is introduced and when the pipeline has the most information about where the off-nod trace is.  

To avoid the issue with the fixed extraction width, would it maybe be possible to define a 2D relative correction that could be applied per-pixel in the array, similar to the barshadow correction?  That way the values would sum as expected, no matter what size the extraction aperture was.

[stscijgbot-jp]

Comment by Charles Proffitt on JIRA:

Hello Melanine:  I worry that doing a 2D correction properly would require the source actually being located where it's supposed to be. When applying the correction globally, one can in principle recenter the extraction box when doing the extraction step to get the correct alignment, but if the source location was already fixed when applying a 2D correction, I don't see that there's an easy way to fix things if its wrong. If nothing else, we'd need to do quite a bit more testing to see how it works in practice.

[stscijgbot-jp]

Comment by Melanie Clarke on JIRA:

Sure, that makes sense.  

If we apply a global correction at nod-subtraction based on a standard extraction aperture, is it in principle fixable later with an aperture correction, if the extraction aperture changes? Or would that also depend on knowing the dither offsets at extraction time?

[stscijgbot-jp]

Comment by Charles Proffitt on JIRA:

The correction table depends on the extraction box size, so you'd have to back the correction originally put in and replace it with the new one.  So I'd think you'd need to know the offsets, and the result would be as complex as just doing the correction during the extraction step in the 1st place. In principle perhaps one could define "aperture corrections" that take that effect into account, but then the aperture corrections would be wrong for the un-dithered case.  In practice, for most dithered FS observations there probably isn't much reason to change the extraction box size, as making it smaller introduces more resampling issues by putting the boundary where there's significant source flux, while making it bigger increases the contamination from the background subtraction of the source.  But for non-dithered observations it might make sense.

[stscijgbot-jp]

Comment by Melanie Clarke on JIRA:

Okay, got it.

In that case, it sounds like it would be better after all to do the correction at extraction time, like a secondary aperture correction.  It seems a little fragile to me to do the correction earlier if it depends on knowing how extraction will proceed later. 

At some point, we will probably want to offer some form of PSF-based extraction for NIRSpec - I imagine it would be easier to figure out how to adapt this correction to that case if it is performed at extraction time.

[stscijgbot-jp]

Comment by Charles Proffitt on JIRA:

For a PSF based extraction, perhaps the best approach would be to skip the pixel-by-pixel background subtraction altogether and then do the fit for the extraction by assuming a known PSF shape + constant background.