IFU source autocentroiding can fail in Ch4C

[stscijgbot-jp]

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

Point source auto-centroiding for spectral extraction can sometimes fail for MRS Ch4C.  Even though sources may be visible at short wavelengths in the cube, the extremely low throughput at long wavelengths can confuse the median-collapsed image.  It may be worthwhile to limit the source finder collapse to wavelengths less than 26 microns, although this may be too source-specific.

[stscijgbot-jp]

Comment by David Law on JIRA:

One possible fix for line 508 of ifu.py: (, , wavetemp) = get_coordinates(input_model, 1, 1) indx=(np.where(wavetemp < 26))[0] collapse = np.ma.median(np.ma.masked_invalid(data[indx,:,:]), axis=0)

[m-samland]

I encountered the same issue for two data sets that I am looking at. However, the source is clearly visible even around 27 micron and if I collapse the band 4C with a nan_median I clearly see the source. I think the issue in my case is that at the very edge of the image there are some very bright spaxels (top right in attached image) that confuse the peak finding, as they are the brightest spaxels in the image.

These bright spaxels do disappear when I limit the wavelength range to <26 micron though. So either restricting the wavelength range or throwing out the outermost spaxels may be a solution to the issue for this data. I think the wavelength cut is a good preliminary fix for this. I think this fix should have high prio, as it potentially destroys the whole extraction at long wavelengths.

[drlaw1558]

Thanks for the example @m-samland ; that looks like some pixels that aren't being masked properly. Can you point me to what the PID/Observation number is for that example you showed above?

[stscijgbot-jp]

Comment by David Law on JIRA:

Addressed by #8199

[m-samland]

Hi @drlaw1558, this was PID 1282 / OBS 35. I tried using the lines of code you posted above and it seems to produce spectra that smoothly connect across the CH4 bands. I still get a message in the log for channel 4C (I think, since it is the last one) that says

WARNING - Auto source detection failed.

I don't know why this message appears in the log, but the output x1d looks good to me.

[drlaw1558]

@m-samland I see what the issue is; due to fine nuances in the distortion solution as a function of wavelength, there are only a couple of spectral planes at the longest wavelengths that contribute to those bright spaxels in your image. (They must be tipping over from one spaxel into the next by some tiny fraction of a spaxel). As a result, the values aren't bad, they're just the median of the longest wavelengths where the background is extremely bright, vs the median of all Ch4C wavelengths that are being used elsewhere in the FOV.

It does look like that's being fixed by the PR above.

The reason you're getting warnings that the auto-detection failed is because auto source-detection is assumed to be looking for point sources. At these wavelengths the extended disk dominates your source morphology, so the routine exits and falls back on using the nominal target coordinates for the aperture extraction instead.

[m-samland]

@drlaw1558 Thanks for the explanation, that makes a lot of sense!

Regarding the source detection: wouldn't a more sensible/robust fall back be to use the successfully acquired position from all the other bands? I would use the mean or median of the measured position on sky in RADEC and use the WCS to convert the position to pixel coordinates in the band in which the source-detection fails. This may require to front-load measuring the position for all bands once, and then replace those in which it failed while printing a warning, so not sure how easy that is with the current implementation.

[drlaw1558]

@m-samland In theory it could, but in practice the individual input cubes are handled independently of each other so there's no trivial way to pass that information between bands (and as you say would need to be iterative in case the first band failed). There can also be meaningful differences between bands due to grating wheel repeatability, although that only matters at the ~0.03 arcsec level.

In your particular case the cleanest solution would be to specify the center position for the extraction directly (--center_xy). Results may be a little odd though since the aperture extraction assumes a point source profile and corresponding aperture correction, while your source has appreciable spatial extent.

[stscijgbot-jp]

Comment by Howard Bushouse on JIRA:

Fixed by #8199