Flux summation in white_light step of TSO3

[stscijgbot]

Issue JP-1355 was created by Bryan Hilbert:

Currently, the white_light step determines the white light signal in NIRCam grism TSO data (and NIRISS SOSS data) by calculating the simple sum of the flux-calibrated 1D spectrum over all wavelengths. By using flux calibrated data for this calculation however, the result can easily be dominated by noisy flux values at the edges of the crossing filter bandpass, where the sensitivity is low and the values in the relresponse curve in the photom reference file are large. 

This was seen in [JP-1174|https://jira.stsci.edu/browse/JP-1174], where the lightcurve for the TSO data was dominated by noise.

A solution to this would be to do the summation over the data prior to flux calibration, in ADU/sec (or electrons/sec since gain varies across the detector).

Another solution would be to do the summation on the flux calibrated data, but use a mean that is weighted by inverse sensitivity. 

Tagging [~kvolk] and [~npirzkal], as these suggestions come from them.

 

[stscijgbot]

Comment by Nikolay Nikolov: For transits, we should use the uncalibrated flux to obtain light curves both white light and spectroscopic. In addition, please employ aperture size big enough to include all of the flux.

[stscijgbot]

Comment by Alicia Canipe: Tagging [~koekemoe]  and [~swara] for visibility

[stscijgbot]

Comment by Bryan Hilbert: At the moment, NIRCam considers this issue critical for commissioning and science operations. The current method results in a white light lightcurve that is not useful. This makes spectroscopic lightcurve analysis impossible. This will impact NRC-33 analysis, as well as Cycle 1 data analysis.

This issue will be discussed in upciming TSOWG and CALWG meetings, at which point the priority may change.

[stscijgbot]

Comment by Kevin Volk: This is not listed as critical because Karl Gordon has expressed doubt that it is needed.  However, if the effect is as Bryan Hilbert has found in the simulations this is of critical concern for the TSO light curve analysis.

[stscijgbot]

Comment by Anton Koekemoer: This issue was discussed in [JWST CAL WG Meeting 2020-05-12|https://outerspace.stsci.edu/display/JWSTCC/2020-05-12+Meeting+notes] and the following items were noted:

• [~kgordon] and [~koekemoe] would consider this a significant change from what was previously requested for TSO; there are implications for calwebb_detector2 and not just calwebb_tso3, so some more general discussion would be needed across the CAL WG

• TSO WG ([Sarah Kendrew|https://outerspace.stsci.edu/display/~skendrew]  [Nestor Espinoza|https://outerspace.stsci.edu/display/~nespinoza] ) will discuss at their next TWSO WG mtg (Wed 20 May), incl discussion with [Nikolay Nikolov|https://outerspace.stsci.edu/display/~nnikolov]  to determine what drives this change, particularly in terms of the need for commissioning and science ops, and they will give a presentation for discussion at next Cal WG mtg 26 May 2020 

[stscijgbot]

Comment by Anton Koekemoer: Changing the ticket type for this from "Improvement" to "Bug", following discussion at [JWST CAL WG meeting 2020-05-26|https://outerspace.stsci.edu/display/JWSTCC/2020-05-26+Meeting+notes] since the issues identified are primarily with implementation of existing specifications (rather than the actual specifications needing to be modified), so that further discussion of these testing results can continue in the DMS WG.

 

[stscijgbot]

Comment by Howard Bushouse: The existing specifications at [https://outerspace.stsci.edu/display/JWSTCC/Vanilla+TSO+WhiteLight+Photometry] say to "Collapse the spectrum from min/max wavelengths (e.g., a simple top hat filter)" and "Summing over the full spectrum to provide a white-light photometry equivalent measurement is useful for quick-look as it provides a simple, easy to visualize measurement of variable sources.  This calculation should be the equivalent of a flat filter response function across the entire spectral coverage of the observation."

This is exactly what the current white_light step is doing: summing all the data over the full range of the spectrum. So how is this an implementation issue, when the implementation does exactly what the specifications say? What am I missing in the specifications?

[stscijgbot]

Comment by Kevin Volk: I agree that this is a specification change not an implementation change.  We did originally assume that the full spectrum would be summed.  But the original discussion way back when was assuming that the spectrum would be in ADU/s as a function of wavelength (i.e. that the extraction and wavelength calibration would be done with the ramp slope files and then the photometric calibration applied after extraction) and then the photometric calibration would be applied.  When the decision was made to apply the photometric calibration to MJy/ster and do this earlier in the pipeline that changed the inputs to the white light step in a fundamental way.  The change in the requirements for the step would have been made at that time, if we had known that it would be an issue.

[stscijgbot]

Comment by Anton Koekemoer: [~bushouse] and [~kvolk]  thanks for the comments, sorry if the above was unclear. The [JWST CAL WG meeting 2020-05-26|https://outerspace.stsci.edu/display/JWSTCC/2020-05-26+Meeting+notes]  minutes provide more details, which I now reproduce here, where (1) it was recognized that there are at least some apparent bugs, which may or may not be related to the wavelength range item, and (2) where I indicate below (in bold) the fact that this specific item (changing the wavelength range) is indeed an enhancement to the specifications-

• The consensus from the resulting discussion is that most of the issues identified by Nikolay are primarily in the context of bugs, ie potential issues with implementation of the beseline specifications (rather than needing a change in the baseline specifications), so that further discussion of it can continue within the DMS WG, this ticket type is now changed to the "bug" category: !https://jira.stsci.edu/secure/viewavatar?size=xsmall&avatarId=13003&avatarType=issuetype! JP-1355 - Flux summation in white_light step of TSO3 OPEN
• The one item that emerged from this discussion as a potential "enhancement" is the idea to restrict the spectral flux summation over a subset of the full wavelength range, ie, excluding the edges of the wavelength range where the flux calibration may be more uncertain, and which may therefore be a potentially significant source of error: [~scrawford]  confirmed that this would be a minor enough change that it could be accommodated within the current time window for new enhancements to be considered for Build 7.6 (ie, by the end of June), if it is of critical priority to the relevant teams; he also confirmed that issues identified here as bugs could be considered for correction in Build 7.6 if reported within the time window for reporting bugs (ie, by mid-July). action was taken by [Bryan Hilbert|https://outerspace.stsci.edu/display/~hilbert]  to file a separate JIRA ticket for this specific item, namely modifying the white-light photometry step in calwebb_tso3 to not sum over the entire wavelength range but instead take input values for min, max wavelength, which would depend on observing mode, and which would be expected to be provided in a parameter reference file - he has since filed this ticket, which is linked to above, ie:  JP-1469

 So discussion about implementing the wavelength min/max range can continue in JP-1469

[stscijgbot]

Comment by Howard Bushouse: The enhancement that allows for summing flux only over a specified min/max wavelength range was implemented some time ago (JP-1469). What remaining bugs need fixing in the current version of the tso_photometry step? It's stated above that there are bugs in the baseline implementation of the specifications, but I don't see any indication as to what those bugs are. If those can be fleshed out, we can get them into the workflow for implementation.

[stscijgbot]

Comment by Bryan Hilbert: Looking through Nikolay's slides (which are linked in one of the the CALWG notes pages mentioned above) it looks like there were a couple other issues, which I think are covered by other Jira tickets/discussions:

Turning off the photom step: https://jira.stsci.edu/browse/JP-2082

Column by column background subtraction when producing the 1d spectrum. (I know there have been separate discussions of this, but I wasn't able to find a Jira ticket for it, other than a generic background subtraction ticket:  https://jira.stsci.edu/browse/JP-277) 

[stscijgbot]

Comment by Howard Bushouse: Column-by-column background subtraction was enabled via JP-1478. It was always available in the extract_1d code, but wasn't selectable for NIRCam TSO until the use of an extract1d ref file was enabled for the NRC_TSGRISM mode. The same option is available for other TSO spectroscopic modes, like NIS_SOSS, NRS_BOTS, and MIR_LRS-SLITLESS, if there are extract1d ref files in place for those modes that have the appropriate params set to request column-by-column subtraction.

[stscijgbot]

Comment by Alicia Canipe: [~nespinoza] [~nnikolov] 

Work on JP-1469 was completed. We have other tickets for TSO issues, as [~hilbert] mentions above. Should we go ahead and close this ticket, and track any further issues in new tickets?