Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JP-2922: Use new source_id syntax for level-3 products #8442

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

hbushouse
Copy link
Collaborator

@hbushouse hbushouse commented Apr 26, 2024

Resolves JP-2922

Closes #7287

This PR updates all the source_id handling machinery within associations, calwebb_spec2 steps, and the calwebb_spec3 pipeline to handle the new source_id syntax for level-3 source-based products, which includes an increase in the number of source_id digits from 5 to 9, and implements the use of "b" and "v" source prefixes for NIRSpec MOS data extracted from background and virtual slits, respectively.

Note that the exp_to_source routine has been updated to use "source_name" as the key for sorting MOS datamodels, because it's the only piece of meta data available that properly distinguishes between "source", "background", and "virutal" slits. source_id values can overlap with one another for MOS now (e.g. a "real" source slit can have the same source_id value as a background slit). Other multi-slit modes (NIRSpec FS and NIRCam/NIRISS WFSS) still use source_id for sorting in exp_to_source, because they don't have source_name populated (names are unknown).

Checklist for maintainers

  • added entry in CHANGES.rst within the relevant release section
  • updated or added relevant tests
  • updated relevant documentation
  • added relevant milestone
  • added relevant label(s)
  • ran regression tests, post a link to the Jenkins job below.
    How to run regression tests on a PR
  • Make sure the JIRA ticket is resolved properly

Copy link

codecov bot commented May 9, 2024

Codecov Report

Attention: Patch coverage is 39.58333% with 29 lines in your changes are missing coverage. Please review.

Project coverage is 57.92%. Comparing base (781e0e0) to head (06bb487).
Report is 4 commits behind head on master.

Files Patch % Lines
jwst/pipeline/calwebb_spec3.py 5.26% 18 Missing ⚠️
jwst/assign_wcs/nirspec.py 58.33% 10 Missing ⚠️
jwst/exp_to_source/exp_to_source.py 80.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #8442      +/-   ##
==========================================
- Coverage   57.93%   57.92%   -0.02%     
==========================================
  Files         387      387              
  Lines       38839    38847       +8     
==========================================
- Hits        22502    22501       -1     
- Misses      16337    16346       +9     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@hbushouse
Copy link
Collaborator Author

Latest regression test run is here: https://plwishmaster.stsci.edu:8081/job/RT/job/JWST-Developers-Pull-Requests/1453/

Unfortunately it includes a large number of unrelated failures, due to an update to a NIRCam photom ref file earlier today. Remaining related failures are due to expected differences in file names and source_id values in multislit files. Will make another run once the truth files have been updated for the NIRCam photom change, just to make it simpler to sort out.

@hbushouse hbushouse marked this pull request as ready for review May 17, 2024 19:46
@@ -310,8 +310,8 @@ def test_msa_configuration_all_background():
dither_position = 1
slitlet_info = nirspec.get_open_msa_slits(msaconfl, msa_meta_id, dither_position,
slit_y_range=[-.5, .5])
ref_slit = trmodels.Slit(57, 8281, 1, 251, 23, -2.15, 2.15, 4, 0, '1x1', 'background_57', 'bkg_57',
0, 0.0, 0.0)
ref_slit = trmodels.Slit(57, 8281, 1, 251, 23, -2.15, 2.15, 4, 57, '1x1', 'background_57', 'bkg_57',
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Background slits now get the slitlet_id value assigned to source_id, which in this test case is 57.

@@ -156,7 +156,6 @@ def process(self, input_data):
model.meta.cal_step.outlier_detection = "SKIPPED"
else:
self.input_models.meta.cal_step.outlier_detection = "SKIPPED"
self.skip = True
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needed to remove this, because outlier_detection gets run multiple times, once for each set of source/slit data in the observation. If one set has the step abort, due to their only being 1 set of input data, we don't want the step to be skipped for all remaining sets of inputs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought I saw that once, reducing MOS data, and never got around to tracking it down. Thanks for the fix!

Copy link
Contributor

@melanieclarke melanieclarke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks good to me. I spot checked some MOS data with virtual and background slits, and found header values as described for SRCNAME, SOURCEID, and SRCALIAS. Filenames from spec3 also looked right.

Copy link
Collaborator

@nden nden left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The new source names for virtual and background slits do not contain the program number any more. Is this on purpose? Is it what users would expect?

source_alias = "vrt_{}".format(abs(source_id))
stellarity = 0.0
source_ra = 0.0
source_dec = 0.0
Copy link
Collaborator

@nden nden May 23, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a change in behavior. Previously source_x/ypos and source_ra/dec for virtual slits came from the msa file. I think it makes sense to get them from the msa file because the assumption is there are sources in those slits. For a program I checked those are set in the msa file and this code resets them to 0 which we probably don't want to do.
In terms of setting these attributes should virtual slits be treated like source slits?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, you're right! I was (blindly) assuming that slits with a virtual source, identified by their negative source_id value in the MSA shutter table, would not have any corresponding info in the MSA source table, and hence was not even bothering to load it. But they do have entries in the source table. For example, here are the shutter table rows for virtual slit 87, which has source_id=-70. And there is a corresponding row in the source table for source_id=-70:

FITS_rec([(87, 88, 4, 345, 1, -70, 'N', 'OPEN', 0.5, 0.5, 1, 'Y'),
          (87, 88, 4, 345, 1,   0, 'Y', 'OPEN', nan, nan, 2, 'N'),
          (87, 88, 4, 345, 1,   0, 'Y', 'OPEN', nan, nan, 3, 'N')],

(1345, -70, '1345_-70', '-09:-039:0.0000 +53:00:57.29', 215.1912160802715, 53.01591471620116, 'None', 0.0)

The x/ypos values are set to 0.5 in the shutter table, so that won't have any change relative to the defaults I had been assigning, but it would result in real values for all the other items, like source_name (1345_-70), alias, ra, dec, and stellarity.

Good catch!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment