JP-2198: Handle MIRI LRS SRCTYPE keyword in extract_1d #6212
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## master #6212 +/- ##
==========================================
- Coverage 77.53% 77.17% -0.37%
==========================================
Files 402 402
Lines 34412 34603 +191
==========================================
+ Hits 26682 26704 +22
- Misses 7730 7899 +169
*This pull request uses carry forward flags. Click here to find out more.
Continue to review full report at Codecov.
|
stscieisenhamer
approved these changes
Jul 13, 2021
loicalbert
pushed a commit
to talensgj/jwst
that referenced
this pull request
Nov 5, 2021
…e#6212) * JP-2198: Handle MIRI LRS SRCTYPE keyword in extract_1d * update change log
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #6208
Resolves JP-2198
Description
This PR fixes a problem with the SRCTYPE keyword not getting copied over to the x1d output of the extract_1d step when processing resampled MIRI LRS fixed-slit exposures. The problem lies in the fact that the
source_typeattribute is defined in the core schema within thetargettree of meta data and also defined in the slitmeta.schema (forSlitModel). When theresample_specstep is applied to MIRI LRS fixed-slit exposures, the input is anImageModelwith SRCTYPE defined within thetargetpart of the meta tree, but the output ofresample_specis aSlitModel, which is created without the SRCTYPE value getting copied to theSlitModel. Theextract_1dis clever enough to look for SRCTYPE in bothmodel.source_type(if the input is aSlitModel) and if that's blank - which it is in this case - then look formodel.meta.target.source_type, where it finds the value. However,model.source_typewas still blank (None) when slit-related keywords are copied to the output x1d model, so the keyword didn't show up.This change simply copies the
source_typevalue to theSlitModelin this situation, so it's available to be copied to the x1d output later in the flow.Checklist