Moving target extraction coordinates not working as expected for IFU

[stscijgbot-jp]

Issue JP-3750 was created on JIRA by David Law:

Prompted by https://jira.stsci.edu/browse/JP-3544, I tried testing spectral extraction on some IFU moving targets as well and ran into some problems.

Specifically, for PID 2361 Obs 5 (MIRI MRS observations of a rapidly moving asteroid) the nominal RA/DEC based extraction location from the final dither-combined data cube is off by 4-5 arcsec.  This isn't obvious though from the default extractions, since MRS sets ifu_autocen=True for point sources by default, meaning that the code will find the source and center up on it anyway rather than trusting the input coordinates.  However, we should fix the bug anyway as it could likely affect NIRSpec too, and would cause issue if there were source confusion.

I've confirmed that the pipeline is correctly building the final ifu cube on the moving_target frame, so that looks ok.  Rather, the TARG_RA, TARG_DEC coordinates given in the dither-combined cube header are those for the first exposure.  The moving target frame however (based on my reading of the documentation) uses the average WCS of the association rather than the WCS of the first frame.

The relevant location to fix this may therefore be in the cube building header metadata blending code.

[stscijgbot-jp]

Comment by Ned Molter on JIRA:

Looking into this, the assign_mtwcs step creates the mt_avra and mt_avdec header keywords, stored in wcsinfo.  It also updates the WCS of all the input models to ensure they get combined correctly.  However, the output cube's TARG_RA and TARG_DEC (meta.target.ra and meta.target.dec) are just transferred over from the first model. 

Setting ifu_autocen=False for the test data gives warnings like "WARNING - WCS implies the target is beyond the edge of the image".  If mt_avra and mt_avdec are used to find x_center, y_center instead, then these warnings go away and the x_center, y_center values look near to the ones suggested when ifu_autocen=True.

The x1d products lack any wcsinfo, so it makes sense that mt_avra and mt_avdec are lost.

My plan for resolving this is to change the cube's (TARG_RA, TARG_DEC) and (MT_RA, MT_DEC) to match (MT_AVRA, MT_AVDEC).  I assume there would be no reason we'd want to keep those values as-is when they reflect just one of the input models.  Hopefully that will make it so no additional changes are needed.

The ModelBlender is already called for IFU cubes in cube_build.  I will try to figure out how to do this within ModelBlender, although I'm concerned we probably don't want to touch the blending rules of TARG_RA, TARG_DEC, so it may be best just to set these outside the blender.

[stscijgbot-jp]

Comment by David Law on JIRA:

Ned Molter I think that sounds reasonable, and should limit the scope of the changes.

[stscijgbot-jp]

Comment by Ned Molter on JIRA:

Thanks David Law , I requested your review on the PR

[stscijgbot-jp]

Comment by Ned Molter on JIRA:

Fixed by #8911 

[stscijgbot-jp]

Comment by David Law on JIRA:

Tested and working after merge to main, closing.