Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. News & Announcements.
  2. Current TSO WG Tasks
  3. JIRA ticket updatesdiscussion
  4. AOBClosing remarks.

Meeting slides

Meeting slides can be found found here

Discussion items

TimeItemWhoNotes
5 mins

1. News & announcements

Everyone





25min2.
 TSO Commissioning Activity Updates
Current TSO WG tasks


  • TSO JWebbinar. First session took place yesterday, led by Sarah Kendrew and Nestor Espinoza (30 Nov.); very positive. Produced some good comprehensive notebooks.
 
  • Next session this Friday.

  • High efficiency modes:
    first
    some
      • . Nestor Espinoza will share amongst the group.
      • Some highlights: clear improvement in precision can be achieved - see plots in slides.
      • Provides pretty strong justification
    is
      • for implementation.
      • Sarah Kendrew asks whether data volume considered/discussed?
    not
      • Not so far - but should factor in there as higher efficiency will produce more data.
      • Michael Regan suggests that it would also be be useful to add info on ngroups to the summary table.
    is
    the detections are
      • a good deal of detections will be marginal so higher efficiency would make a
    differences
      • difference to the most challenging proposals
    .for
      • . In particular, this is important for the TRAPPIST-1 proposals. Nestor Espinoza did include a citation to the work of Natasha Batalha which goes in detail on this exact same point, but might be good to reiterate it on the docuement.
      • For MIRI we can in principle actually do
    ngroups
      • Ngroups = 1  if we don't care what it looks like. NIRISS will be doing this
    in commissioning. 
      • as well. 100% efficiency mode thus would be a huge improvement to those prospects.

    • NIRSpec pipeline validation: the gift that keeps on giving
    be really weird
      • behave weirdly on CV3 data.
    finds
      • Finds 10s of thousands of jumps in a small subarray (basically all the background pixels).
    found
      • Found this was due to negative background counts, produced by group-to-group flux variations
      • This was fixed by removing "background" levels studying "non-iluminated" pixels. Simply took the median of first 10 and last 10 rows, and that made the algorithm to behave better. However, Nestor Espinoza mentioned jumps are predominantly detected around 1/f banding and on the center of the trace, as small trace position variations make small intra-pixel variations to produce larger-than-threshold flux variations. This latter might be a particularity of the NIRSpec CV3 data (which had larger-than-expected jitter).
      • Michael Regan is suspicious of this 1/f banding effect. He suggests it is most likely a reference file problem rather than an algorithmic problem. Nestor Espinoza mentions he is pretty sure the reference file is being generated "correctly", i.e., taking the combined variance as the read-out-noise of everything (1/f + white-noise) in the darks. He will investigate further.
      • Michael Regan shows reservations on using "background" pixels as pseudo-reference pixels, because it's hard to identify in general where "non-iluminated pixels" are located. Nestor Espinoza suggests this is relatively easy to do in general for TSOs. Perhaps that could be implemented there. Thomas Beatty mentions this is what they do in their own NIRCam data analysis pipeline. 
      • Michael Regan suggests maybe one should just drop the jump step for subarrays
    (as these have no reference pixels)
  • should add an extra step after ref pixel correction step to manage this in cases where there is no ref pixels
  • could somehow detect the pre-amp resets independent of flux and correct...?
      • for which there are no reference pixels. Nestor Espinoza is not very keen on this idea; the jump step is a good step, it just needs a bit of "help". Michael Regan shares that he's been working on an algorithm that uses TSO information to compute the jumps; Nestor Espinoza shared that this is exactly what he does on his own pipeline, and this should be the way to go.
      • Nestor Espinoza will open a ticket (or multiple ones) to address this. 
    25min3
    . Non-linearity correction work10 mins4. 1/f noise discussion2 mins5
    . JIRA ticket discussions


    Everyone
    • First-group behavior/analysis (JP-2071)
      • Michael Regan introduces the fact that currently, the pipeline "forces" the usage of the superbias as a zeroth-group in order to calculate ramps for single-group integrations. This might be problematic first because it might be inaccurate if there are temperature variations, but also because of a lack of consistency: if this method for obtaining ramps is good, why not use it for all ramps? An extra group-time would be gained (more details on the discussion here).
      • He suggests that this should be optional. And that the possibility of doing single-group integrations using the superbias as the zeroth-group should be studied with multi-group integrations (in order to have some ground truth).
      • Nestor Espinoza suggests a good action item for the TSO WG could be to study this with the TSO commissioning datasets. This way, the stability across exposures of doing this could be studied in detail. Enabling it or "suggesting" it for use for exoplanet science, for instance, might be dangerous to do before this is actually tested.
    • Pixel-level time-stamps (JP-2330)
      • Nestor Espinoza points to this ticket and introduces the problem: given the readout of JWST detectors is sequential, certain pixels have a different time-stamp than others. This needs to either be (a) fixed/provided by the pipeline or (b) coded up so users can fix this in their datasets. He asks whether we know precisely the clock timing of pixels.
      • Michael Regan answers that yes, it is known to be 10 micro-seconds; the row/column wait time is based on those clock-times. Nestor Espinoza asks if this has any tiny uncertainty associated with it; Michael Regan suggests that this is not the case.
      • Being that the case, this will be brought to the CalWebb WG on January then as an item to work on pipeline-wise. Discussion will be tracked in the Jira ticket.
    2 mins4. Closing RemarksNestor Espinoza