View Source

One of the main tasks of the TSO WG on FY2020 is to perform testing of the steps made by the JWST Calibration Pipeline for TSO-like data. This tracking sheet contains all the information regarding pipeline testing by the members of the TSO WG. Nestor Espinoza and Sarah Kendrew will be populating this page heavily in the weeks of July 20 and 27, 2020, for NIRISS and MIRI TSO testing, respectively. Nikolay Nikolov and Tony Keyes will be populating at their own pace for NIRCam and NIRSpec, respectively.

General guidelines for Pipeline Testing

Please, test every step identified below. If for some reason you don't have time to test a step, let Nestor Espinoza and Sarah Kendrew know.
Use the comments in the tables to post brief comments about the status of that testing step (think of it as a quick overview for others to know what is going on). For extended commentary, or details on how you performed the testing, use the text below the tables.
If a bug is found, please report it in Jira as a "Bug" Jira ticket. Please copy the links to those tickets in the table below under the comments.
For algorithm improvements/enhancements, please file an "Improvement" Jira ticket. Please copy the links to those tickets in the table below under the comments.

In general, if bugs are found, the best would be to discuss them first in one of our meetings before going ahead and submitting them (unless this is high-priority, in which case we could schedule a special meeting for this). This is left at the discretion of each TSO WG member.

General comments

Before jumping to read the below table, some important comments to keep in mind while reading them:

NIRISS testing is being done using awesimsoss NIRISS/SOSS simulations of K2-141 (which has a short transit duration, hence the selection). Care must be taken as this is the first end-to-end simulation of awesimsoss (which is under active development). In-progress notebooks of each stage testing can be found here.
MIRI testing is being done using MIRISim simulations of MIRI/LRS.
NIRCam testing is being done using Mirage simulations.
NIRSpec testing is being done on CV3 data.

Stage 1: Detector Processing TSO testing

Pipeline step	NIRISS status	NIRISS comments	NIRCam status	NIRCam comments	MIRI status	MIRI comments	NIRSpec status
group_scale		The step is supossed to do nothing for NIRISS/SOSS (here, a group = 1 frame). Indeed, nothing changes when running this step, except for the length of the ASDF element in the HDU list object, which is normal.			N/A
dq_init		This step correctly initializes the data-quality flags, as it is supposed to do, according to the reference mask in CRDS.
saturation		This step does what is expected to do: it captures saturated pixels and flags them in the GROUPDQ masks. The simulations used for this validation had saturated pixels and they were correctly identified (flagged) by the pipeline.				done for imager. only high level check for LRS.
superbias		Tested my own bias substraction using reference files and got exact same results.			N/A
reset	N/A		N/A			This was tested on a TSO imaging file separately since this step does not currently run by default. The test passed with no issues.	N/A
linearity		Tested linearity correction using reference files and got exact same results.				sufficiently covered by unit testing.
rscd	N/A		N/A			Step currently flags frames in integrations higher than the first as 'DO_NOT_USE' in the groupdq array. This has been tested successfully.	N/A
dark_current		Dark frames perform expected corrections on the data.				sufficiently covered by unit testing
refpix		Currently, does not do anything to NIRISS/SOSS simulations, as reference pixels there are set to zero. When injecting a fake strain of reference pixels got some deviations that most likely have to do with DMS-detector frame rotations.				This step is sufficiently tested in unit tests. It is skipped for MIRI subarray data so only applies to FULL array imaging TSOs, and note that MIRISim's implementation of Refpix is different from the pipeline step, so may give unexpected results.
jump		Step produced no errors. However, currently detecting more jumps than it should — will revisit once some errors on the SOSS simulator are addressed (see below).				high level testing is done. Inserted cosmic rays of varying strengths were detected (based on threshold) and flagged neighboring pixels (based on level above background)
ramp_fitting		The pipeline was tested against an OLS ramp fit, and pipeline does exactly as intended.		produced rateints with 7.5 and independent linear fits; substantial difference in a subset of data.		Well covered by unit tests. May be a candidate for more detailed testing when time.
gain_scale		This step only applies to NIRSpec data. Because no GAINFACT is found in the headers, this step is properly skipped by the pipeline.				Documentation states 'This currently only applies to NIRSpec exposures that are read out using a subarray pattern, in which case a gain setting of 2 is used instead of the standard setting of 1.' This step is properly skipped for MIRI data.

Extended comments by instrument branch:

NIRISS: For the jump detection algorithm, the pipeline seems to be detecting a large fraction of jumps (~20% per integration). This is most likely due to a mismatch between reference files used to generate the simulations and the ones used to reduce the data, which ultimately leads to badly calculated errorbars, which might be giving rise to bad jumps. Will re-check this step once this is solved by the simulator, but the jump step seems to be doing what is intended to do.
NIRCam
MIRI:
NIRSpec:

Stage 2: Spectroscopic processing TSO testing

Pipeline step	NIRISS comments	NIRSpec status	NIRSpec comments
assign_wcs	Assign WCS indeed adds information to the ASDF name of the files. Tested that ranges of the WCS information made sense.
extract_2d	This step is not supported for NIRISS/SOSS, and indeed running this steps shows the "not-supported" message. Still, saves an output equal to the input.
flat_field		Build 7.5: Failed current validation test	passes for NRS2, but fails for NRS1: JP-1071 -NIRSpec: flat_field calspec2 step failing validation for FS ALLSLITS, BOTS, and MOS data OPEN
srctype		Build 7.5: Logic is not correct, always defaults to POINT, even when provided EXTENDED	JP-1576 - source_type logic in spec2 is not correct for NIRSpec FS and MOS modes OPEN
photom
extract_1d	This step currently extracts the whole subarray as a spectrum, which produced order overlap, which makes this step produce an unusable product for science. An algorithm is in development for this step. For details, see .	Build 7.5: methodology needs to be vetted by TSOWG	additional comments pending

Extended comments by instrument branch:

NIRISS:
NIRCam
MIRI:
NIRSpec:

Stage 2: Image Processing TSO testing

Pipeline step	NIRISS status	NIRSpec status
assign_wcs	N/A	N/A
flat_field	N/A	N/A
photom	N/A	N/A

Extended comments by instrument branch:

NIRISS:
NIRCam
MIRI:
NIRSpec:

Stage 3: Time-Series Observations (TSO) Processing testing

Pipeline step	NIRISS status	NIRISS comments	NIRCam status	NIRCam comments	MIRI status	MIRI comments	NIRSpec status	NIRSpec comments
outlier_detection
tso_photometry
extract_1d
white_light

Extended comments by instrument branch:

NIRISS:
NIRCam
MIRI:
NIRSpec: