Closed stscijgbot-jp closed 9 months ago
Comment by Alicia Canipe on JIRA:
A note for tracking: this issue was raised after investigation of Help Desk ticket INC0189809.
Comment by Norbert Pirzkal on JIRA:
I do not mean to tell anyone how to implement this, but if the pipeline has a 2D image with the center wavelength of each pixels, the dispersion can be computed from that image down to a descent level of accuracy.
Comment by Alicia Canipe on JIRA:
Reassigning to Anton Koekemoer and Greg Sloan for CalWG input.
Comment by Anton Koekemoer on JIRA:
Adding Kevin Volk and André Martel for NIRISS – please examine whether or not this issue has NIRISS impacts, and edit the 'criticality' fields accordingly if you could please.
Comment by Kevin Volk on JIRA:
I am not able to understand why there is a factor of 10 problem in the NIRCam WFSS photometry calibration from the description in the ticket, so it is difficult to comment on whether there is some NIRISS equivalent. In the general sense for the SOSS mode we have a wavelength reference file that gives wavelengths pixel by pixel across the field and this allows for the (small) changes in dispersion over the array. In that mode the assumption is that all sources are at the same position so we do not need to worry about changes as a function of where the source is located in the direct images.
For the WFSS mode the dispersion does not appear to be a strong function of wavelength or position on the detector, although some small variations are measured. This does not appear to be an urgent issue, but I can take it to the WFSS sub-group within NIRISS for comments.
Comment by Norbert Pirzkal on JIRA:
The source of the factor of 10 in the spectroscopic calibration comes from the sensitivity being delivered as Mjy/sr/lamba while the pipeline assumes that it is in units of Mjy/sr/"pixel" where "pixel" is the wavelength range of a dispersed spectrum across a pixel. If NIRISS has assumed all along that field dependence and variation is not an issue and has calibrated things assuming that nothing varies on the detector then it should not be an issue (at least to within the error that this assumption introduces).
Comment by Anton Koekemoer on JIRA:
This is among the CalWG tasks prioritized in the quarterly development priorities meeting with WMO 2023-09-06
Howard Bushouse could you let us know please who from SCSB has been assigned to this, so that they can start working with Norbert Pirzkal Kevin Volk André Martel and others for the next steps in proceeding with this effort?
Comment by Robert Jedrzejewski on JIRA:
Hi foks, I'm starting to work on this. Which modes need to be corrected?
Any others?
Comment by Greg Sloan on JIRA:
I don't believe LRS slitless has any issues here. Or it might be better to say that if it does, then we've corrected for it with our current photometric calibration. Any changes to how the pipeline handles the photometric calibration from pixel space to extracted spectra would require a fresh delivery of reference files for photometric calibration.
Comment by Kevin Volk on JIRA:
Robert Jedrzejewski I do not think that this applies to the NIRISS WFSS or SOSS modes. For WFSS the traces are relatively short and we have assumed that the dispersion per pixel is constant over these traces. This seems to be OK. For SOSS mode there is some small change in dispersion with wavelength but this is handled in the photometry reference file and since the traces are in a fixed position on the detector to a good approximation there is no problem with the way things are handled.
Comment by Robert Jedrzejewski on JIRA:
Thanks Greg Sloan and Kevin Volk . For NIRCAM, I'll only look at NRC_WFSS and NRC_TSGRISM, as NRC_GRISM data only runs through the detector1 pipeline.
Comment by Anton Koekemoer on JIRA:
hi Robert Jedrzejewski can you point us please to the source for the modes you mention? (eg NRC_WFSS vs NRC_GRISM, and others)
I'd like to compare the place where you found those modes, to the one used for PPS by JSSE ([https://innerspace.stsci.edu/display/JSSE/Templates+-+modes])
Thanks in advance!
Comment by Robert Jedrzejewski on JIRA:
Hi Anton Koekemoer , I used this table:
https://jwst-pipeline.readthedocs.io/en/latest/jwst/pipeline/main.html#pipelines-vs-exposure-type
Also, I tried running the spec2 pipeline on a NRC_GRISM rate file and it failed with a message about being unable to find a WAVELENGTHRANGE reference file, so I suspect that there aren't entries in the crds rmaps for NRC_GRISM data
Comment by Howard Bushouse on JIRA:
Anton Koekemoer Originally "NRC_GRISM" was used for any NIRCam mode that had a grism in the beam, including the WFSS science mode. Meanwhile NIRISS WFSS mode was using EXP_TYPE='NIS_WFSS'. So many years ago we had SDP modify the "NRC_GRISM" value that it gets from front-end systems and change it to "NRC_WFSS" when storing EXP_TYPE in the FITS headers for NIRCam WFSS exposures - for consistency between NIRCam and NIRISS WFSS modes. But the old "NRC_GRISM" value is still used for exposures taken in the NIRCam engineering mode, because there were some other parts of the ground system (e.g. commissioning tools) that depended on that original value. So that's why we have a mixture of values.
Comment by Anton Koekemoer on JIRA:
thanks Robert Jedrzejewski and Howard Bushouse
And yes, the reason I asked was exactly for what Howard Bushouse describes, ie: on the front-end PPS side the template is set to "NRC_GRISM" for any non-TSO grism NIRCam data, including both science and engineering data:
So I just wanted to make sure that the list of "modes" that Robert Jedrzejewski posted earlier were not the PPS observing modes (where "NRC_GRISM" is used for both science and engineering) but were in fact the values populated in the FITS header EXP_TYPE keyword.
Ie, yes, if the list from Robert Jedrzejewski refers to the FITS header EXP_TYPE keyword, then I concur that we only need to worry about science modes here for NIRCam and not engineering modes, so the relevant EXP_TYPE vales are then "NRC_WFSS" and "NRC_TSGRISM"
Thanks for confirming!
Comment by Howard Bushouse on JIRA:
Fixed by #8207
Alicia Canipe Bryan Hilbert Reminder to please take a look at this and confirm that it's now fixed the original issue as expected.
Comment by Bryan Hilbert on JIRA:
I've checked this and the results look good to me. I've sent my results and a note to Norbert Pirzkal, asking if he wants to do any further checking
Great, thanks Bryan Hilbert . Closing for now then, but please feel free to reopen if Norbert Pirzkal comes back with any issues.
Issue JP-3238 was created on JIRA by Alicia Canipe:
NIRCam is working on addressing an issue with the interaction of the flight WFSS/TSGRISM flux cal files with the current design of the photom step, which is causing the flux calibration to be off by a factor of 10. The near-term fix will be to divide the PHOTMJSR values by 10. However, this triggered a discussion that dividing by 10 is not quite right – the dispersion varies across the detector, and is also wavelength dependent, so we can't just create a 2048x2048 array of dispersions and extract 2D boxes. Instead, the pipeline needs to know the wavelength at each pixel in order to find the dispersion. This is something that needs to be done individually for each source in the FOV. Forcing a pixel size/sr/bin size to the sensitivity will always be an approximation and introduces an error in the flux calibration. Because it's a small variation, it will probably not be noticed until the contamination and background subtraction are resolved, but we should begin investigating this issue to improve the quality of WFSS data products.
The photom step already creates the 2d array of wavelength values for each source. A 2d array of dispersion values would have to be constructed on the fly for each source and the pipeline would have to know the function for calculating dispersion.