Discussion items

Integration Time Tagging
  • Kevin: JWST clocks drift by (~14) microseconds per second

    -- not well shielded from thermal fluctuations

    This could affect the Slope images because the "flux/s" might vary from group to group

    Marcia Rieke: the pixel clocks will not vary, only the recorded times.
    -- this can be fixed in post-processing
    -- time = time_start + num_groups * time_per_group
    -- Tom/Jarron/Everett also confirm laboratory results

    Kevin: Bigger issue:
    The clock gets adjusted 'automatically'
    -- possibly during a science exposure

    They are going to change the time-correction `dribble` was changed from 16 u-sec per second to 1 u-sec per sec

    Proposed Solutions
    1) Special telemetry mnemoinc (called SCTA_OFFSET)

    2) Use instrument clocks

    3) Stay in units of electrons

    Kevin: What is the focal plane electronics temperature variation?
    Marcia: We can't know about it on orbit, but it could be a few degrees

    Kevin: JStans wrote that there should be a 0.36ppm / K stability
    -- if the drift is a few K, then we are looking at ~1ppm over that drift

    Marcia: OTIS is probably a better estimate of that stability

    Jarron: We don't need to necessarily access the FPE clocks, because he can just update the headers or add a keyword that has the pre-computed integration time

    Loic/Kevin: agree

    Kevin: then as long as our slopes are computed with respect to the frame-time clocks, we can make accurate e-/s counts

    Tom: Either way, we are limited in absolute time by the spacecraft clocks

    Kevin: can we access the clock in the FPE?

    Tom: Do we need that?

    Kevin: That is the next question. Do we trust the instrument clocks enough for relative time calibrations

    Jarron: Yes. definitely. we tested that in the lab and in OTIS/CV3

    Marcia: the FPE pages (?table information) can be either fast or slow; and the FPE clocks may be on the slow pages which (?) update every 10 seconds.

    Kevin: Do all instruments keep the same instrument clock settings?

    Jarron: I know the NIRCam and NIRSPec keep different clock settings. Especially if NIRSpec uses IRS2 mode.

    Marcia: Every instrument uses a slightly different telemetry stream

    Loic: for NIRISS it is ... (?)

    Kevin: {ACTION ITEM} STScI representatives need to find the equations for how long an integrations takes for each instrument and mode. Needed for DMS to design how to compare the timing arrays.

    Pierre: NIRSpec has TSO-like data from CV3

    Loic: Same for NIRISS (TSO-like data from CV3)

    Kevin: [Action Item] examine timing arrays from CV3 TSO-like data

 Instrument Bias + Saturation  
  • Kevin: The community does not know what to qualify as "saturation"
    Could each team make recommendations to the community here?

    Marcia: We can look it up quickly. But it should be ~80% full well
    -- that is well into non-linearity, but NL can be correct to high precision.

    Tom: Could you recommend what level is desireable?

    Kevin: We are looking for ~1% after correction

    Loic: Each team for TSOs has its own saturation levels that converge to magnitude limits.
    -- i.e. NIRSpec 65k for saturation; NIRISS has 72k, etc

    Kevin: what is your definition for saturation

    Loic: I think it is 90% full well

    Kevin: and what about non-linearity?

    Loic: the NL grows linearly with %FW, so at 90% FW, it should be about 9% non-linear

    Kevin: What about the error on the correction?

    Loic: That is a fair question, but not necessarily trivial. We need to look into second order effects.

    Kevin: We don't want the community to push towards the 90% saturation limit without knowing the caveats.
    -- we want the community to be able to estimate their level of risk.
    -- there has already been confusion in planning obs

    Loic: Okay. The error on the NL correction results in an error on the PPM of the final spectrum.
    -- a 1% error on NL is a 1% error on the ppm
    -- it is probably a second order thing
    -- the bigger question is how is your results effect by saturation

    Kevin: That is more reason to advise people to stay away from saturation.
    -- should people avoid saturation completely

    Jonathan: do you mean saturation at the first group or anywhere up the ramp?

    Loic: it matters depending on the error (i.e. persistence). if we saturate at group=10, can we use groups 1-9?

    Jarron: If we use groups 1-9, then we are making assumptions about the errors. any time we make assumptions about the persistence, we are added error into the results.

    Loic: will any proposal be rejected if there is any saturation anywhere?

    Kevin: They will definitely not reject saturated proposals, some peoples' science depends on it.

    Kevin: Sarah gave slides that suggest MIRI might recommend saturation because if you have less than 5 groups, then there is difficulty in stability (1st/last frame effects).
    -- if we run through 6 frames (saturated), then the last frame effect is on the saturated frame, instead of the last science frame.

    Marcia: We should also inform people that the throughputs may be off by as much as 10%, which will affect these limits as well.

    Marcia: one last thing: the JDox page says "check saturation limits with ETC"; so we (IDTs) need to make sure that the ETC is giving the right saturation limits.

    Tom: The JDox pages give a more favorable result. The ETC may be using a static Gain for each instrument

    Jarron: Everett, did you compare our simulations with the ETC?
    Everett: Yes. a few months ago.

    Maria: Tom, could you have the student you mentioned send us the notebook? We would like to check these numbers with our ETC

    Loic: For NIRISS, the agreement is well below 5%

    Marcia: For NIRCam, it depends on which SCA you are on. The values on the screen ( are not what we expect for NIRCam.
    -- the LW detectors should say max pos. sat. ~80k
    -- the SW detectors should say max pos. sat. ~100k

    Loic: For NIRISS, we have it at 90%

    Maria: For NIRSpec, 65k counts already include bias

    Kevin: [ACTION ITEM] Could each team rep send me those numbers in an email, with caveats for how we got these numbers -- to add to JDox

    Pierre: These values are delivered to the ETC, if we send it in an email, then the ETC gets new numbers and we don't send new numbers to JDox, then there could be inconsistencies.

    Kevin: We want to make recommendations to people that are aligned with the ETC; so please send us the ETC numbers.

    Jarron: I am looking at JDox now and see that the numbers match, but in ADU instead of electrons.
    -- Is it possible that the units on the ExoCTK page are in ADU instead of e-?
    -- the numbers on ExoCTK match the ADU from JDox
    -- the numbers on the Jdox for e- is correct

    Marcia: for (..?) SCAs, we can basically digitized full well above the bias level

Nominal Aperture/BG Sizes
  • Kevin: DMS is designing CalTSO3-Spec.
    We need to get nominal aperture sizes for integration with vanilla pipeline to extract spectra
    -- Jonathan looked at the NIRCam data and found 22 pixel box (+/-11 from the spectrum) for aperture; then 42 pixels for bg

    Marcia: keep in mind that the bottom 4 pixels are the reference pixels and not background pixels.
    -- but the pipeline should also incorporate the reference pixels into tracking DC-level offsets, outside of the flux-background levels.

MIRI Update
  • See slides

Action items



  1. Kevin Stevenson

    For MIRI our definition of saturation in the ETC corresponds to 70% of full well, and the number takes into account non-linearity correction. Let me know if you need more details.

  2. Sarah Kendrew: The MIRI numbers that I see are 193655 for the recommended ETC limit and a maximum of 250000.  Do you recommend 70% of 193655 or 250000?  Do these values take into account the bias level?