Allow WCS shifts in individual IFU exposures when building cubes.

[stscijgbot-jp]

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

https://jira.stsci.edu/browse/JP-2500 described a number of enhancements that would be useful for the cube_build routine with regard to specifying the tangent point, size, etc of IFU data cubes to be built.  Most of that ticket relates to how the cube itself it to be set up, but the requested ra_shift and dec_shift ability is a fundamentally separable topic.  This ticket therefore splits out that part of the work into a different package.

Cube_build should allow for values ra_shift, dec_shift that give an arbitrary coordinate shift in arcsec to be applied to the cube cloud coordinates in RA/DEC prior to projection into the xi/eta space.  This allows for a cube-space fix to the known WCS issue based on user-defined inputs.  There would need to be an ra and dec shift value for each input frame, so in practice it may be simpler for cube build to read these values from a table of corrections generated by the user (or some TBD non-pipeline notebook, e.g. using simultaneous imaging data).  This table would contain one row for each input file in the same order as the association file.  This is an entirely optional parameter that would be used for offline rereductions rather than MAST data processing.

[stscijgbot-jp]

Comment by Howard Bushouse on JIRA:

I believe similar options are available in either tweakreg or resample for imaging data, whereby a user can specify per-image WCS specifics. We should look at how those were implemented and perhaps use the same kind of user interface for cube_build.

[stscijgbot-jp]

Comment by Jane Morrison on JIRA:

David Law Is it left to the user to determine the shifts to apply to each input cal. It would be really nice if we had a script or notebook to help the user determine this. Is there anything out there ?

Also we know a a data set where the wcs is off   that I could use to test with.

 

[stscijgbot-jp]

Comment by David Law on JIRA:

Jane Morrison Yes, we're leaving it to the user to determine what the shifts should be.  There was some work on how to determine these using simultaneous imaging data a while back, but nothing generic that came out of it.

For a test data set, try PID 1524 Obs 17.  This is observations of 10 Lac in a normal dither pattern, but repeated for 3 full sets of ABC gratings to test wheel repeatability.  You can measure clear shifts between positions in (say) 2B between successive observations of 2B.  See Fig 10 of Patapis+24.

[stscijgbot-jp]

Comment by Jane Morrison on JIRA:

@⁣Tyler For this ticket I was going to have a new input list that contains 3 columns  filename ra shift  dec shift. Is there any format or file type I should use for this list. I am assuming this will be something users run off line.

[stscijgbot-jp]

Comment by Jane Morrison on JIRA:

David Law  I grabbed the PID 1524 Obs 17 data. I created a set of band cubes for each exposure (so 2 cubes per exposure).

I set up a test to try and determine the offsets. I think I must be doing something wrong. I took the channel 2-Medium cube and collapsed along wavelength and centroided on the source. I did the same thing for channel 1-Medium. My assumption(which could be wrong) is that these centroids would show a similar trend - but maybe that is not correct. I have a plot for the centroids of 6 exposures in this observation for ch1 and ch2. I ordered them as 

jw01524017001_06101_00001mirifushort red jw01524017001_06101_00002mirifushort blue jw01524017001_12101_00001mirifushort. black jw01524017001_12101_00002mirifushort purple jw01524017001_18101_00001mirifushort green jw01524017001_18101_00002mirifushort orange I subtractecd the first exposure of ch2-medum from all the others ch2-medium values and likewise from the ch1-medium.  offsets are in arc seconds on the plot. I was expecting the same color points to be closer together. Maybe also my centroiding method needs improvement.  Suggestions.  !image-2024-08-09-06-40-36-623.png|width=518,height=482!

[stscijgbot-jp]

Comment by Jane Morrison on JIRA:

David Law Tyler Pauly 

The format of the input offset list is unclear.  Should I used an asdf format. Pro - that seems to format of many input files, con - if user are to make this file then we might need to extra documentation on how to make as ASDF file. In fact I am going to have to remind myself how to do this.  We don't really have any other step (that I know of ) that accepts an input file for the user. 

[melanieclarke]

I was just working with ASDF inputs for another reason: the output_wcs parameter for the resampling step takes an ASDF file as input. It's actually pretty easy to make an ASDF file from a python dictionary, which might be a more useful format for input than a table of files and offsets anyway.

For example:

import asdf
offsets = {'file1.fits': [.00001, .00001], 'file2.fits': [-.00001, -.00001]}
af = asdf.AsdfFile({'offsets': offsets})
af.write_to('offsets.asdf')

And to read them in again:

with asdf.open('offsets.asdf') as af:
    offset = af.tree['offsets']

[stscijgbot-jp]

Comment by Jane Morrison on JIRA:

Melanie Clarke Wow thanks. It does look much easier than what I have done in the past. 

Thanks I will go with asdf for starters since that is a standard that will work with the pipeline. 

 

[stscijgbot-jp]

Comment by David Law on JIRA:

Jane Morrison The offsets won't be the same from channel to channel as they are due to grating wheel repeatability issues.  When this is the cause of the offset (i.e., not pointing errors) then the offset should be almost entirely along alpha, the sign of the offset will be the same in Ch1/4 and often the negative of that in Ch2/3, but the magnitude in units of arcsec can be different in all four channels.  I've been treating each band individually when measuring shifts.  If it helps, you can find the code that I used to measure the centroiding at https://github.com/STScI-MIRI/MRS_Distortion/blob/main/Cubes_CenShift_FLT7.ipynb