Header errors in MIRI MRS SIR2 test data

[stscijgbot]

Issue JP-736 was created by David Law:

Mock data produced for the MIRI MRS in SIR2 and retrieved from MAST exhibits a number of problems with the FITS headers in the uncalibrated frames.

For program 825, observation 13 should have been a 4-point dithered MRS observation using the Channel 2 - optimized point source dither pattern.  I downloaded the uncal.fits data for exposures 2-4; the first-extension header of exposures 2+3 use V2REF, V3REF keyword values appropriate for the MIRI imager, not the MRS.  The values for exposure 4 look like they correspond to a location in the FGS, not the MRS.  This matches with the APERNAME and PPS_APER values in the primary header, which are MIRIM_FULL and FGS2_FULL; both are incorrect, they should be MIRIFU_CHANNEL2A.  V2REF, V3REF keywords for the MRS should always be tied to MIRIFU_CHANNEL1A for all MRS exposures, regardless of the actual aperture in use.

Similarly, the target observed was meant to be at (RA,DEC)=(80.47, -69.51), which agrees with the TARG_RA and TARG_DEC keywords from the exposures 2+3 primary headers (but not exp 4).  If the RA_REF, DEC_REF keywords in the first extension header are to be believed though then the MIRI Imager is pointing at (RA,DEC)=(79.60, -68.91) and therefore the science target is about 2400 arcsec away; far outside the FOV of any of the JWST instruments...

 

• Minor header oddity: primary headers of MRS exposures contain the CHANNEL=’12’ keyword, but the comment says 'NIRCam channel: long or short’.  I think it must be pulling the wrong thing out of the keyword dictionary.  
• Minor header oddity: primary headers of MRS exposures contain the FILTER keyword appropriate for the imager.  Does this really need to be included as it has no effect on the MRS detector data?  
• Minor header oddity: CRPIX, CTYPE, etc keywords are given for the MRS uncalibrated data, which is totally bogus.  Pixels in no way map to RA—TAN, etc.  The CRPIX values used for exposures 2+3 are the reference point for the MIRI imager, and for exposure 4 look like they are probably the reference point for the FGS?

[stscijgbot]

Comment by David Law: Have now been able to look at some data from program 850 as well; even for cases where MRS is the only instrument taking data (no simultaneous imaging, no FGS) the APERNAME (and associated V2REF, V3REF keywords) are still incorrectly set to MIRIM_FULL.  From the files that I looked at, it also seemed like the crossed-dichroic information was not set properly in the headers for this program.

Another comment: It would be super-helpful to be able to see the BAND keyword as a column in the MAST interface!  I don't see a way to enable this?

[stscijgbot]

Comment by Rosa Diaz: I assume you already know this. PID 825 Obs 13 is a coordinate parallel with FGS

[stscijgbot]

Comment by David Law: Right; FGS should be taking parallel data, but the science target should always be in the MRS for all 4 dither positions.

[stscijgbot]

Comment by David Law: Adding other comments from my original email here just for completeness:

• As folks have already observed, not all of the data seems to be in MAST.  For program 825, for instance, there should be 4 sets of exposures taken with F1800W using both the MRS+Imager+FGS (observation 13).  I can see all four exposures in MAST for the imager and MIRIFULONG, but only three for MIRIFUSHORT.
• According to the 825 APT file, observation 13 should have been a 4-point dither using the MRS Channel2 point-source pattern.  MAST only displays the correct target name and RA/DEC for exposures 2 and 3 though, exposures 1+4 have target UNKNOWN and RA,DEC = 0,0.  This is presumably related to all of the above issues where the telescope seemed to 'point' at the FGS for some of the dithers?
• The pointing file that I export from the APT file looks strange; MIRIFU_CHANNEL2A is interleaved with FGS2_FULL entries.  Why does FGS show up in the pointing file when it is being used simply to take parallel data?  (This may simply be a misunderstanding on my part of the information that is meant to be contained in a pointing file)
• When trying to download data from MAST I ran into a disk space problem: "Error: There is not enough space on the disk. . If this problem continues, please send an error report to archive[at][stsci.edu|http://stsci.edu/].”  MAST helpdesk has fixed this now, but it may be worth noting as a snag that came up during analysis.

[stscijgbot]

Comment by Misty Cracraft: Who should be looking into these issues? Alberto just brought up the same header issue of channel being defined as a NIRCam keyword in GSEG3 files. Should we assign this to a specific person since it looks like it hasn't been addressed since it was filed in May?