2021-06-02 TSO WG Meeting notes

Brian Brooks brings some announcements/news to the WG:

• Reminds the WG of the LRE4 activities happening on June 14-22. TSO WG falls in the middle, so important to consider this.
• He also mentions that the beta version of APT 2021 is ready internally for use/testing. Has several of the warnings already mentioned in previous TSO WG meetings (including phase-constraint warnings, for instance). Should be the one to use to perform IS reviews.

Everett Schlawin brings up the photom step discussion on the CalWebb WG (see notes here). In summary, CalWebb WG reluctant to leave photom step off by default. Had sent the task our way to find a correction to possible jitters in the data which can then make the photom step to properly work. This sparked an interesting discussion:

• Thomas Beatty explains they ran some simulations: if you simulated pointing jitter as per expected one by JWST, photom step is a problem, as it currently adds 20-30 ppm to the noise level. This is because photom step does not follow the jitter. Any correction to this effect needs to be done before the photom step.
• Nestor Espinoza is surprised to find then that the CalWebb WG was not willing to leave the photom step off by default given this result. 20-30 ppm is small, but it is still not zero. If it is adding that level of noise, would think most users will turn step off for relative flux studies, which are likely the majority of the studies to be performed.
  
  
• Michael Regan asks a little bit more detail as to why this effect appears and how people are thinking of correcting it. It seems. to him the problem is being thought as if pixels had edges, whereas NIR pixels do not have sharp edges; there's diffuse boundaries between them. Also asks whether you wouldn't be dominated at the end by, e.g., flat fielding errors.
• Thomas Beatty agrees that flat field error (aka, pixel-to-pixel and intrapixel variations) are the dominating factor at the end. 
  
  
• Nestor Espinoza adds that the photom step is just adding an extra layer of "noise" to the equation with not much to be gained. Yes, calibrated spectra is useful on most settings as an extra product (e.g., activity characterization in transits, Thomas Beatty mentions some uses on phase-curves as well), but in general relative measurements are the norm. Don't see a good reason to leave it on for now given a correction needs to be made/thought of/corrected before this step is set "on" by default. Also can't think why previous members would have wanted it to be on; will contact Nikole Lewis and Kevin Stevenson to figure that out.
• Everett Schlawin suggest that perhaps this was thought for photometry in the past; whereas for spectroscopy this has a much more complex framework.
• Michael Regan suggests that if the standard user wants it off, then that should be a good argument to leave it off.

Michael Regan also mentioned the fact that the overall calculation of "photon-noise" is most likely wrong at the pipeline level. One doesn't work with counts directly; times for each pixel are not returned. Gains might be off. Nestor Espinoza asked if he could give the TSO WG a presentation on these issues on the next TSO WG meeting; Michael Regan agreed:

• Michael Regan will present on the next TSO WG meeting details on why currently the pipeline has troubles on calculating the real, underlying "photon" noise.

Nestor Espinoza

Based on the discussion. on the previous TSO WG meeting, Nestor Espinoza and Sarah Kendrew organized a meeting with various stakeholders (JDox leads, JWebbinar leads, Mission Office, etc.) to share the willingness of the TSO WG to work on important documentation topics (see meeting notes of that meeting here; check slides for details). Discussion arose from this:

The 1/f noise study is on the modelling stage:

• Nestor Espinoza has code to fit the PSDs for each instrument and simulate integrations with that. However, he's worried that some of the structure seen on NIRSpec and/or NIRISS darks could be uncorrected odd/even effects, and/or other effects not properly corrected by reference pixels and/or previous pipeline steps. Loic Albert asks where in the PSD these peaks appear — Nestor Espinoza can't remember the exact frequency, but it was close to the column-to-column jump frequency, which made him think it could be an uncorrected row-to-row effect.
  
  
• He will be meeting with Unknown User (aroy) and Diane Karakla next week to discuss this. Michael Regan and Loic Albert interested in joining the meeting as well.
  
  
• In the context of CV3 darks, Loic Albert mentions that after 4 integrations, the NIRISS detector were reset in chunks of 512 rows. Suggestion that this could explain some of the peaks in the PSD? Nestor Espinoza douts it, as Unknown User (aroy) ran analyses on integrations individually as well. Would be good to touch base on that on the "satellite" meeting mentioned above.