Date

Slides & Recording

Slides: Please contact the TSO CT Leads (Nestor Espinoza, Munazza Alam, Aarynn Carter) for a link to the slides.

Meeting slides:  

Attendees

Agenda

  • News & Announcements
  • Previous and upcoming TSO observations
  • NIRcam Grism Offset Position
  • Reinstating FAST on MIRI

Discussion items

TimeItemWhoNotes

2 min

News & AnnouncementsAll
  • No news or announcements.


5 minPrevious & upcoming TSO observationsAlam
  • Some proprietary information, so nothing to report on the notes. Nothing out of the ordinary.

NIRCam Grism Offset Position


  • JP-3842; this is about how APT interacts with the pipeline.
     
    • APT lets you specify X and Y offsets. However, the pipeline doesn't track this. 
    • It tracks shifts in the X direction but not on Y directions. So it gets the trace position wrong.

  • Everett Schlawin notes there might be some edge cases (e.g., moving because of a binary, etc.), but probably not a widespread use case.
  • We don't think it would be OK to let the pipeline do the y-offset. Should be kept in APT to help users accomodate observations (e.g., the binary case above)

    • However, there should be a caveat somewhere in that a simple offset could give suboptimal results (eg, not optimal flux calibration, not optimal wavelength solution).



Reinstating FAST readout on MIRI
  • Ian Wong introduces FAST vs FASTR1 readouts:

    • FASTR1 readout reads every frame with a reset:

      • This was implemented to reduce the RSCD effect. Exact cause is not fully understood. Perhaps related to exponential decay rates. 
      • By adding this reset, you reduce this effect — but you get a worse duty cycle. 
      • There's a proposal to revert to a FAST readout to get a much higher duty cycle.

    • Is there a interest in the TSO community to restore the FAST readout mode — ie, one without a reset? 

      • This would enable highest duty cycle.

        • Report by Espinoza & Batalha (2022) shows that you could in principle gain an overall increase on the precision of measurements.
        • You can do brighter objects too.

    • Introducing the FAST readout however, has costs:

      • Report by Gordon+2020 shows there's an exponential rise which produces a systematic offset between the first and the rest of the integrations. This manifests as extra systematics on the rates per integration, because it gives rise to a change on the slope at least on the very first integration (there might be smaller offsets on further integrations).

      • So — one con of implementing this is that you would have a worse RSCD.

      • Another one is that you might reduce the dynamic range. You need to change the bias voltage if you change to the FAST mode. You can't change from FAST to FASTR1. Michael Regan notes however that because you change the saturation value, you still have the same dynamic range. Ian Wongasks whether

    • In terms of tests, FAST was never used in flight so we do not have tests to TSO data:

      • Ground testing was limited. 
      • Is not clear if the increased SNR in FAST would counter the systematics introduced by RSCD.

    • In summary:

      • Not clear if we should reinstate FAST or keep going with FASTR1.
      • No apparent strong voice in the community asking to reinstate FAST.
      • Making the change will incur in substantial FTEs.

    • Discussion:

      • Nestor Espinoza notes gain is on observations that use multiple observations — if you get better SNR per event, then you ask for less number of events (e.g., eclipses, transits, etc.). It would be good to do tests on FAST. People might solve RSCD in the future, or at least account for it.
      • Michael Regan notes this is a fight between random noise and systematic noise. RSCD is really hard to solve. There is even a per pixel RSCD effect that needs calibration. 
        • His view is that RSCD is a lot of work to handle.
        • Trading systematics for random noise might be complex.
      • Taylor Bell feels similarly to Michael Regan. He notes some GTO folks are aware of these FAST versus FASTR1. FASTR1 is worthwhile — having understood RSCD so far, it's hard to visualize it would be better to trade systematic noise (FAST) for random noise (FASTR1).
      • TSO CT voted — and people did not think it would be good to move back to FAST.

MIRI odd/even row systematics
  • Report by NL & DG on MIRI/LRS odd/even effects on ramps (check slides).

  • There's no active tickets to work on this, study, perform some type of corrections, etc.

  • Given it's been so long — because we don't have updates, we should perhaps:
    • Close the Helpdesk ticket. Say to Nikole and David we're working on this.
    • Open our own ticket to work on this.
    • Work on this!

  • Taylor Bellnotes he's seen this as a function of wavelength too. Him and Michael Regan note this is RSCD related.
    • He shows slides on which he notes he sees the same things on "image lightcurves".

  • Ian Wong notes this is good to keep track off. 
  • Hannah Diamond-Lowe notes:
    • We don't know what MIRI was looking at, but we know the filter. This might have an impact on the strength of the ramp at the start of the integration. 
      • An idea on this direction would be to put a filter before TSO slewing.
    • On the post-processing:
      • Trying to understand range of ramps that can happen based on previous flux would be nice:
        • e.g., pointing to a nearby bright thing, then going to a source, and seeing the impact.

  • Michael Regan notes impacts on persistence might even come from the background.
  • Achrene Dyrek asks whether this happen before or after TA, or if TA could be the cause.
  • Aarynn Carter notes this implies there's good agreement this needs to be worked.

MIRI systematic flux drop on a TSO mystery
  • To keep the identity of the program secured, we don't put it here. Check slides.

  • Suggestion is to:
    • Close the Helpdesk ticket. Say thank you to Michael for flagging.
    • Open our own ticket to work on this.
    • Work on this!
  • Ian Wong had a quick look at this in the morning:

    • Background seems to be constant.
    • Centroid position of the trace is constant.
    • The width of the trace position seems to show a slight uptick.
    • Also checked number of bad pixels — but no particular issue.
    • Perhaps something going on on the imager array?
  • Still a mystery!
5 minClosing remarks

Action items

  • No labels