NIRSpec MSA nodding extraction

[mmaseda]

Hi,

In a recent NIRSpec MSA GO program, I'm encountering an issue with the creation of the 2D files and the subsequent 1D extractions. All of my sources appear to be in the bottom part of the 2D spectra, even when they are actually centered in e.g. a 1x3 microshutter configuration. I'm attaching an image of one of the targets, which is clearly in the center of a 1x3 configuration (the bright emission line and the continuum are from the object). Yet, the 2D reduction shows it pretty low down, and the 1D extraction mostly misses the target entirely. I don't know if this is a bug, or in the *msa.fits file that is being used (which I also got from MAST), but there is an issue here. Any help is appreciated!

[tapastro]

Hi,

I would wager that the issue lies in poor instrument model reference files leading to poor WCS construction/alignment - but I would strongly recommend you ask this question on the JWST Help Desk here: https://stsci.service-now.com/jwst?id=sc_category&sys_id=e15706fc0a0a0aa7007fc21e1ab70c2f

You can select the NIRSpec team to get an up-to-date status on reference files and if they have seen or expect this problem of MSA data. If the NIRSpec team believes this to be a pipeline issue, we will investigate!

[tapastro]

One thing to add:

If the ticket progresses slowly, as long as the spectral trace is in the 2d extracted region (which looks a bit iffy in your example...), you can set the explicit extraction region of the extract_1d step with a custom reference file. A template can be pulled from what currently exists on CRDS, e.g.: https://jwst-crds-pub.stsci.edu/browse/jwst_nirspec_extract1d_0003.json

There, you can specify the pixel extent of the bounding box for each aperture by providing the keywords 'ystart' and 'ystop'. I don't yet have much experience with MSA data, so I don't know if there is a straightforward method for modifying the bounds for each extracted slitlet bounding box individually - my guess is that there isn't, as it looks like each aperture has the same "ID" in some test data I have. Still, it might provide you with a better result than what you have currently.

You would use your modified reference file by specifying it as, e.g. from the command line: strun calwebb_spec2 {input_rate.fits} --steps.extract_1d.override_extract1d={custom_extract1d.json}

[jdavies-st]

Note that NIRSpec updated their instrument model reference files at CRDS_CONTEXT jwst_0930.pmap on the ops server. See the whole history of CRDS updates:

https://jwst-crds.stsci.edu

Check that you're using a CRDS context later than that. It will be in the CRDS_CTX keyword in the FITS header of your _cal.fits files.

[mmaseda]

Thanks for the suggestions! I've been making some progress on this, and I think most of the issues stem from the msa.fits configuration files.

One thing that seems like it shouldn't matter but does seem to is the actual order that things appear in the "SOURCE_INFO" part of the msa.fits files. Let me give an example using jw02593001002_01_msa.fits. I'm focusing on msa_metadata_id=209. For dither_point_index=1, source 35 (which does not reduce by default) is inside slitlet_id=232. The other slitlets with slitlet_id=232 show up like this inside the msa.fits "SOURCE_INFO" extension: [(232, 209, 2, 311, 147, 0, 'Y', 'OPEN', nan, nan, 1, 'N'), (232, 209, 2, 311, 148, 35, 'N', 'OPEN', 0.4447597, 0.8007014, 1, 'Y'), (232, 209, 2, 311, 149, 0, 'Y', 'OPEN', nan, nan, 1, 'N')] So far, so good - things are ordered by column and the source is contained in the central shutter. But in dither position 2, it looks like this: [(301, 209, 2, 311, 149, 0, 'Y', 'OPEN', nan, nan, 2, 'N'), (301, 209, 2, 311, 147, 35, 'N', 'OPEN', 0.44785777, 0.78560877, 2, 'Y'), (301, 209, 2, 311, 148, 0, 'Y', 'OPEN', nan, nan, 2, 'N')] Things are no longer listed in column order. Compare that to the corresponding entry for source 326, which does reduce correctly: [(291, 209, 2, 172, 151, 326, 'N', 'OPEN', 0.3080974, 0.44047156, 2, 'Y'), (291, 209, 2, 172, 152, 0, 'Y', 'OPEN', nan, nan, 2, 'N'), (291, 209, 2, 172, 153, 0, 'Y', 'OPEN', nan, nan, 2, 'N')]

I was surprised to find that the order matters this much, considering in all of these cases there is only a single target inside any of the shutters. But in digging around I found the "get_open_msa_slits" function inside assign_wcs (https://jwst-pipeline.readthedocs.io/en/latest/_modules/jwst/assign_wcs/nirspec.html?highlight=source_info#), and in line 662 I think it assumes that things are ordered in a very specific way that doesn't seem to be true for some targets: source_id = slitlets_sid[0]['source_id']. Now, why the order is different for some objects and not others, I have no idea. But I had some success manually editing the msa.fits files and putting things in order. There are still some things going on that I haven't cracked yet, but this is progress. Has anyone else seen this before or understand what is happening?

Thanks again!