Rule: NIRCam WFSS

[stscieisenhamer]

Related to #239 but otherwise no specifics yet.

[stscieisenhamer]

Dependent on issues #598 #239 #639

[stscieisenhamer]

Implementation

Constraints

• No filtering out on anything other than image or grism. All filter combos allowed.
• file names need allow for three optical elements: filter-short, filter-long, pupil
• Do not allow cross-observation associations.

  Level2

  Image association

  This will be the direct image exposures.

  Spectral association

  This will be the grism exposures, including the catalog and segmentation map produced by the image3 processing of the direct images.

  Level3

  Image association

  Produce the direct uber-image, catalog , and segmentation image for use as input to the Level2 Spectral processing. Since an uber-image will not be done for 7.3, a catalog will be used from the potential list of catalogs available. An attempt will be made to associate the "closest" catalog to their respective grism observations, as determined by APT. "Closest" means the first direct image taken after the grism exposure in question.

  Spectral association

  Produce the source-based spectrum files.

ToDo

• [x] documentation
• [x] tests
  • [x] setup tests resolved in #3162
    • [x] Resolve how out-of-field images will be handled Resolved: With uber-image construction, out-of-field images will simply be included.
    • [x] Since the grism is only in the long channel, will data simultaneously be taken in the short? Similar to the direct/out-of-field images? Resolved: Data will be taken. Until otherwise specified, such data is marked as imaging, and will be processed as such.
    • [x] Both modules? Resolved: Yes, APT has decreed it so.
• [ ] code
  • [x] level2 image no special processing required
  • [x] level2 spec
    • [x] refactor members to be a class and have an item attribute
    • [x] Change the Association.have_items to be a property to look through the members.item
    • [x] Association.finalize collect all the direct_image members and determine the right catalog name.
    • [x] ensure the catalog is included.
    • [x] Pick the catalog from a direct image that is >= EXPSPCIN of the exposure.
    • ensure the uber image is included
  • [ ] level3 image
    • [ ] same target
    • [ ] same candidate
  • [ ] level3 spectral
    • [ ] currently constrain on filter. However, make future issue for changing this.
    • [x] how to distinguish "out-of-field" exposures. Or, do they need be distinguished? Currently no need to distinguish

[hbushouse]

Constructing the level-3 direct image ASN will be a bit tricky. The Grism Working Group wants to first produce a combined direct image for each different filter that was used for the direct images, and then a special routine does the combining of those images into the uber image. So we may need to specify output product names for the filter-specific products (images, source catalogs, segmentation maps), and the uber products (final uber image and the source catalog and segmentation map resulting from it). So perhaps a scheme in which we define multiple products, such as:

[prod-filter1]
   name = <...>_filter1_i2d.fits
   [members]
     filter1-exp1
     filter1-exp2
     ...
[prod-filter2]
    name = <...>_filter2_i2d.fits
   [members]
      filter2-exp1
      filter2-exp2
      ...
[prod-filter<n>] 
      ...
[prod-uber]
    name = <...>_uber_i2d.fits
    [members]
        <...>_filter1_id2.fits
        <...>_filter2_id2.fits
        ...

[stscieisenhamer]

This can be done. Or, does calwebb_image3 want just a single list and it sorts out the filter stuff itself?

[hbushouse]

Right now I think that calwebb_image3 assumes there'll be only 1 product specified and works on just the first one, but that could easily be expanded to loop over products.

[stscieisenhamer]

Question

What is an "Out Of Field" image? For NIRCam grism, this is part of the sequence. Does it need to be in any association?

[sosey]

Updated information - we no longer need the segmentation map in the association, only the uber image and uber source catalog are being saved. The source catalog itself will contain the bounding box information for the objects - and this will be used by the grism pipeline. https://github.com/STScI-JWST/jwst/issues/739#issuecomment-328912868

out-of-field image -> is this one of the grisms or a member of the association that created the mosaic direct image which the catalog was made from?

or is out-of-field image an orphan member of the association that doesn't connect on-the-sky to any other exposures of that area?

[stscieisenhamer]

In the example proposal we have, in the exposure sequence, there is an exposure type listed as 'out-of-image'. when looking at the sql, these exposures occur at the end of the first grism, and if 'both' is specified, they appear between the two grisms. hence, they seem to exist, but don't know the purpose or science to them.

[sosey]

ahh, I think it's these expsosures, which are used probably for contamination measurements laters?

Direct images occur automatically at the end of the dither sequence and three positions are imaged: one at the final dither position, and two additional fields in each direction parallel to the dispersion axis to cover the out-of-field sources.

from here: https://jwst-docs.stsci.edu/display/JTI/NIRCam+Wide+Field+Slitless+Spectroscopy

[philhodge]

That's not necessarily contamination, it could be useful data, just with the undispersed target off the detector.

[sosey]

That too, but they know that off image objects, outside of the imaging FOV, are getting dispersed onto the detector when the grism is in use and they need to figure out where that light originated. In any case, It's probably best to get the team to specify how they want the pipeline to handle these images. :smile:

[hbushouse]

I'm guessing they would be part of the list of direct image exposures that become members of the level-2 and level-3 direct image ASN's, so that the final combined image from calimage3 covers additional area outside the grism FOV and hence those slightly off-FOV targets will get detected and included in the source catalog. calspec2 can then choose to do whatever it wants with those sources in the catalog.

[stscieisenhamer]

Presuming "out-of-field" are just more "direct image" is actually a good thing. Otherwise, there appears to be no way to distinguish between the actual direct images and the out-of-field images. The only difference would be the dithers involved. If we need to depend on dither differences, that would make a very fragile system. Its possible the dither pattern indicator may help on that, but would have to see actual data to confirm.

Further clarification/status: APT does denote the intent difference between the direct and out-of-field images. However, it is recorded in a field, apt label, that has had a sordid history and is on the verge of being eliminated completely. Currently in discussion with APT developers where it is recognized that this should actually not be the case. A PR will be filed shortly to document/implement an appropriate solution. This will most likely take a bit of time.