search

spacetelescope / jwst

Python library for science observations from the James Webb Space Telescope
https://jwst-pipeline.readthedocs.io/en/latest/
Other
571 stars 167 forks source link

Verify that descriptions of dither-related keywords for NIRCam are current #3193

Closed stscijgbot closed 5 years ago

stscijgbot commented 5 years ago

Issue JP-560 was created by Alicia Canipe:

Since dither-related keyword definitions in the [keyword dictionary|https://mast.stsci.edu/portal/Mashup/Clients/jwkeywords/index.html] are probably old, please verify that descriptions of the dither-related keywords are still current, and if not, provide an updated description in this ticket to match the current situation. If you know that a given dither-related PPSDB parameter is slated to get updated in the next APT version (27.1), please change the description accordingly. Paul G. will encourage Ops leads to make sure that future updates to APT templates be communicated to DMSWG counterparts so the associated keyword descriptions can be sync'ed up, if necessary. Please verify this for your SI by COB March 7th, and add any relevant information to this ticket.

 

Here is the relevant (current) PPSDB information:

[http://www-int.stsci.edu/dsd/cns/database/r2d2/pps_dev/nircam_imaging_dither.html]

 

This is related to the discussion organized by Paul Goudfrooij: [https://innerspace.stsci.edu/display/JWST/2019-02-25+Meeting+with+DMSWG+on+Dither+Keyword+consistency+across+SIs]

stscijgbot commented 5 years ago

Comment by Paul Goudfrooij: Hello - checking in for status?

stscijgbot commented 5 years ago

Comment by John Stansberry: Recommended changes to the nircam_imaging_dither table in PPSDB (linked in the Description above). A general note is that the term 'secondary dither' and 'subpixel dither' are used interchangeably, which is not quite optimal. Suggested wording below indicates the equivalence and is probably adequate to address any uncertainty that might result from using two terms for the same thing.

 

Field 'dither_size':

This field is only available in APT if the primary dither type is INTRASCA, and the size of the dither no longer depends on the PPSDB value for the camera field (see [NIRCam Imaging Template Parameters|https://jwst-docs.stsci.edu/display/JPPOM/NIRCam+Imaging+Template+Parameters).

Change the description to this much shorter version:

This field indicates the qualitative size of the INTRASCA dither pattern. The 3 allowed values are SMALL, MEDIUM or LARGE, with the resulting overall size of the dither pattern being 8", 16" or 24", respectively.

 

Field 'subpixel_dither_type':

When NIRCam is the sole instrument operating, this field indicates whether standard dithers, executed via a SAM, or small grid dithers, executed via FSM offsets, are to be performed. For coordinated parallels with NIRCam prime, it indicates whether to use a pattern optimized for that parallel mode, or the NIRCam-only standard pattern (small grid dithers are not supported for coordinated parallels). This field is not actually available in the WFSS template, as suggested by the current description.

Change the description to:

When NIRCam is the sole instrument, this field records whether STANDARD or SMALL-GRID-DITHER secondary (or subpixel) dithers should be performed. When NIRCam is prime in a coordinated parallel observation, this field records whether to use the usual NIRCam-only subpixel pattern (small-grid-dithers are not available), or the name of one of the patterns optimized for that parallel combination.

 

Field 'subpixel_positions':

This field is only available for 'standard' secondary (or subpixel) dithers, inconsistent with the description.

Change the description to:

When the subpixel dither type is STANDARD, this field records the number of dither positions to

 

Field 'small_grid_dithers':

Small-grid-dithers, using the FSM to offset the source on the detectors, are available in Imaging, Coronagraphy, and Engineering Imaging templates, so the description for this field is incorrect.

Change the description to:

This field records the name of the small grid dither pattern when subpixel_dither_type is set to SMALL-GRID-DITHER in the Imaging, Coronagraphic Imaging, or Engineering Imaging templates. The value indicates the number of positions in the pattern and, in some cases, something about the geometry of the pattern.

 

 

 

stscijgbot commented 5 years ago

Comment by Paul Goudfrooij: Hi John, there seems to be a slight misunderstanding as to what updates are needed in the context of this ticket. We can submit your suggestions Re: the descriptions of dither-related PPSDB information to PPS, but what this ticket is about is the descriptions of the dither-related Header Keywords for NIRCam in the [JWST Keyword Dictionary|https://mast.stsci.edu/portal/Mashup/Clients/jwkeywords/index.html]. One specific NIRCam-related item that came up in the meeting on 2/25 was that NIRCam should consider introducing the PATTSIZE keyword, inheriting its value from the "dither_size" PPSDB parameter. (As you state above, this is only relevant for the INTRASCA primary dither pattern type, but it still seems relevant to include it as header keyword, being left empty if another dither pattern type is selected.)

stscijgbot commented 5 years ago

Comment by John Stansberry: Could you point me at a ticket where someone else has satisfied this request? I think it would help me understand the scope and perhaps find an efficient way to respond to it.

The keyword dictionary doesn't have a description, per se. Is the request to review everything that appears in the Value column and update that? For example under NIRCam -> Imaging -> NIRCam Dither Information -> Patttype  it has:

  |Attribute|Value| |type|string| |sql_dtype|nvarchar(15)| |calculation| | |default_value|NONE| |example|FULL| |units| | |sw_source|PPS:nircam_imaging_dither.primary_dither_type| |source|Proposal and Planning System (PPS)| |level|1b| |si|NIRCAM| |section|Dither| |mode|NRC_IMAGE, NRC_SLITLESS, NRC_TACQ, NRC_CORON, NRC_FOCUS, NRC_DARK, NRC_FLAT, NRC_LED, NRC_WFSC| |fits_hdu|PRIMARY| |special_processing|undefined| |destination|NircamScience.patttype| |enum|WFSC, FULL, INTRAMODULE, INTRASCA, NONE, FULL-TIGHT|

 

'mode' appears to be incorrect in that it includes templates that don't support dithers.

'enum' appears to be incorrect because it lacks all of the patterns introduced into the PRD some time ago after Dan Coe re-worked the dither patterns (e.g. INTRAMODULEBOX, INTROMODULEX, ...) That is assuming that the 'enum' attribute is supposed to be a list of the allowed values, which is just a guess on my part.

'source' is something that I don't necessarily know. Should I ignore that?

 

If instead I look at NIRCam -> Imaging -> NIRCam Dither Information -> SUBPXNUMS, it appears to only allow an integer value. I don't see a place where the existence of our many subpixel patterns, including small grid dithers, can be supported at all.

 

It looks like there are 5 modes, 7 tables each. Am I to review all fields in all of them? It looks to me like some of these aren't 'reviewable' until populated, e.g. the XOFFSET and YOFFSET tables.

 

Alternatively, perhaps a systematic attempt should be made to see what's in a modern version of the PRD and try to make sure all of the dither fields and their values can somehow be represented in the keyword dictionary. That would seem to be a better process than us adding something in PPS, PPS getting it into the PRD, and then the Keyword Dictionary not having a system or procedure for picking up those updates.

stscijgbot commented 5 years ago

Comment by John Stansberry: Re. the issue w/ PATTSIZE being a string for NIRCam, I believe the 2/25 CIOWG discussion resolved the issue...?

See this https://jira.stsci.edu/browse/JWIT-19?focusedCommentId=316936&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-316936 on JWIT-19.

stscijgbot commented 5 years ago

Comment by Paul Goudfrooij: John, Re: your comment on the scope of this ticket (which is perhaps more a DMS ticket than an Ops ticket, but it kind of straddles the boundary between them): what we mainly want to know is the following:

As an example, I submitted a ticket JWSTKD-305 to add NIRISS dither-related keywords to the data headers. (It is currently being worked and still somewhat in flux.) Below are some examples for which you may want to request updates or changes. 

As I understand it, 'mode' lists the modes for which the header keyword shall appear in the data. (And its value will be empty if the mode in question doesn't support dithers.) But if you want to remove a given keyword for a given mode, you can request that as part of this effort.

if the values in 'enum' for a given keyword are incorrect or not up-to-date, it would probably be useful to specify the changes needed. But I think specifying that level of detail is less important, because if indeed DMS gets the values from the PPSDB and the latter is updated in response to an APT ticket, I would think those updates should automatically transfer to DMS, is that correct [~rdiaz] or [~acanipe] or [~swade] ?)

I understand that 'source' isn't necessarily something we know (as Ops lead), but it is something we can confirm or verify. And if we want to suggest a new dither-related keyword, we need to specify where its values should come from (which often will be the PPSDB.) 

I don't think I understand your comment Re: the SUBPXNUM keyword, but I'll ask you in person. (Is the issue perhaps that you want to create a keyword that holds the name of the sub-pixel pattern? If so, then yes, that would have to be created and added to the header keywords for NIRCam, and hence that would have to become one of the items to request as part of this ticket. Looking at the nircam_imaging_dither PPSDB table, it looks like you would want the values of such a keyword to come from the "subpixel_dither_type" parameter.) 

And yes, the XOFFSET and YOFFSET keywords will be populated on the fly, using the values in the various dither tables in the PRD. The "reviewing" part for such keywords is just to confirm (or deny) that the statement in the 'calculation' attribute is the proper thing to do.

stscijgbot commented 5 years ago

Comment by John Stansberry: I've added detailed comments on the CIOWG page for this issue:

[https://innerspace.stsci.edu/display/JWST/2019-02-25+Meeting+with+DMSWG+on+Dither+Keyword+consistency+across+SIs]

There is significant work needed to support dithers where the '# of points' requested can be a string, and to then provide the needed data to the keyword dictionary in a way that is consistent with the PPSDB.

stscijgbot commented 5 years ago

Comment by Paul Goudfrooij: Thanks, John. In response to your important comment that the value of nircam_imaging_dither.primary_dithers in the PPSDB is formally a string rather than an integer so that it requires code/logic to convert it into an integer, I'd like [~swade] (or [~rdiaz], or an assignee) to comment on whether such code/logic is already available. I see in the description of NUMDTHPT for NIRCam Imaging that its source is "nircam_imaging_dither.primary_dithers|numdthpt_int|", and I'm wondering whether that [numdthpt_int] indicates an already existing translation/conversion. 

stscijgbot commented 5 years ago

Comment by Alicia Canipe: I think we have reached a conclusion here for NIRCam. If everyone agrees, we can go ahead and close this ticket. I will create a JWSTKD ticket for the NIRCam updates John mentioned in the notes linked above.

stscijgbot commented 5 years ago

Comment by Alicia Canipe: We've had extensive discussions about this, and I think reached a conclusion. See https://jira.stsci.edu/browse/JWSTKD-309 for requested keyword updates.