Wavelength Calibration Errors with OSIRIS DRP

[mikekoss]

We are reducing an OSIRIS Kbb taken on 11/2/2017. There is a shift of about -8.37 nm of the spectra across the board (e.g. a telluric absorption line -- Brackett Gamma -- that should be found at ~2166.12 nm seems to be at 2157.75 nm, and atmospheric absorption characteristics seem to be also shifted to a shorter wavelength by an equal amount based on what we find with xtellcor. We have reduced a number of other data cubes without such a large offset, tried re-reducing with the latest developmental pipeline, updating our DRP_directory/data subdirectory etc., and the problem persists. Has anyone else seen such large offsets? Is a linear shift possible to fix this (would guess not)?

[mikekoss]

This is what the shift looks like.

[mikekoss]

It appears to be in both the standard star and object observations.

[followthesheep]

This is an unusually large offset. What plate scale are you using? Do you see this from other nights? The wavelength solution in 2017 in Kn3 35 mas has an average offset of 0.07 Angstrom and a standard deviation of 0.05 Angstroms. See plot below:

[jruffio]

I have data reduced from 20171103 (day after), which showed an offset in Kbb 20mas (different platescale) of roughly 13km/s based on OH lines. This is about ~1/3 of a pixel or a little less than 0.1nm. This is a bigger offset compared to other datasets I have looked at, but still far from 8nm.

[mikekoss]

@followthesheep We don't see this in other nights. This is for the 0.05'' scale. @jruffio Do you happen to have osiris_wave_coeffs file you used for 20171103 (we used osiris_wave_coeffs_170509_180316.fits). We looked on the KOA reduced data, it also has these large offsets.

[jruffio]

Sure, but I cannot see why it would be different. I have never touched these myself; just git pull. Tuan has been telling me to use the develop branch of the pipeline though, so maybe that's the difference? I will let Tuan chip in :).

[mikekoss]

@jruffio Okay thanks, when did you do the reductions? Maybe they were changed somehow?

[jruffio]

The time stamp on my files says 03/21/19.

[jonvwill]

The reductions Mike posted above were done in the last month, but as he says, the reduced files in the archive for 11/2/2017 also show the same uniform offset.

[followthesheep]

@jonvwill can you post the xml file you used to reduce the data?

[jonvwill]

The reduction was done using the ODRFGUI facility, so it was done in steps. I've copied the completed xml files from my DRF_QUEUE directory into one file (attached).

A few notes: 1) The "apply_mask.py" facility was run against all frames prior to starting (15 sigma) 2) In an attempt to reduce noise, each of the three star frames was reduced against the three related sky frames, resulting in nine reduced frames. Those were mosaicked together after inspection (files were renamed after each run to avoid overwriting). 3) Inspection of individual frames prior to mosaicking showed the same wavelength shift in all.

001.s171102_a003_drf.txt

[jonvwill]

Also, for reference, here's the calibrations.xml file used.

calibrations.txt

[mikekoss]

@jruffio Is the data you mentioned public? Just was trying to look and see on the KOA it had the same offsets. But I don't see anything for OSIRIS. It's been a few years so I am surprised it isn't there.

[jruffio]

Mh yeah, I don't see it either. I am not the PI of the data so not sure what's going on. I just rereduced the data and it looks fine with the latest pipeline (development branch). But it's a different platescale, so could be a problem specific to 50mas.

[followthesheep]

The xml file looks fine. This might be a problem with the data this night. We did extensive analysis of the wavelength solution in 2017, so it's one of the most well characterized years for OSIRIS. Kbb 50 mas has a shift of about 0.32 Angstroms in 2017. Below is the analysis of the wavelength solution at different filters and scale (also in the manual).

Some suggestions:

• try looking at the temperature keywords in the header to see if OSIRIS was anomalous -- if the temperature is very different, it can affect the wavelength solution.
• compute the wavelength offset from fitting the sky lines and applying that offset the science data

[jonvwill]

I've looked at an Hbb-filter observation from the same night, now. I believe a shift is seen in this band, as well, but smaller (perhaps due to 4th order vs 3rd order for K band) -- about 6.3nm.

In H-band, the shift in frequency of frequent hydrogen lines result in significant distortion of the output spectra when standard star correction is attempted.

(In these graphs, the yellow line is the expected atmospheric absorption)

Below is the standard star spectrum with hydrogen line correction, and below that is the resulting observing target spectra.

[mikekoss]

@followthesheep @jruffio would it be possible for someone to just run through a 1 frame reduction for us to see if you have the same wavelength offsets. We don't seem to have the problem on other nights. If you just download OS.20171102.56424.fits (that's a H band of the star) or OS.20171102.56146.fits (which is K-band) from the KOA, I would really appreciate it. Most of the time wavelength offsets are highly non-linear, at least from my experience with other spectra, so it's going to make fixing them really problematic.

[followthesheep]

@mikekoss I can help with this next week, but what I need is a sky frame and dark frame. Can you point me to those?

[mikekoss]

Hi @followthesheep thanks so much. We actually didn't do sky/dark subtraction on the star. But @jonvwill can share with you the names of those files.

[followthesheep]

It would be good to get a sky that has long enough exposure time to see the OH lines since they are what we use to quantify the stability of the wavelength solution.

[jonvwill]

Tuan, From that evening, the dark frames I used were: OS.20171102.07749.fits OS.20171102.08712.fits OS.20171102.09676.fits

Example object frame for a Kbb filter: OS.20171102.47503.fits Example sky frame for Kbb: OS.20171102.48179.fits

And for Hbb: Object: OS.20171102.53658.fits Sky: OS.20171102.54008.fits

[mikekoss]

@followthesheep that's a good point, the sky lines would be really helpful.

[jonvwill]

The sky frames above were 600 s (Kbb) and 300 s (Hbb) exposures.

[followthesheep]

@jonvwill could you email the files to me? I am not good at searching KOA.

[jonvwill]

Yes. To clarify, you primarily need the sky frames?

[followthesheep]

Yes, and a dark at that integration time.

[jonvwill]

Actually, this might be easier. I'll attach them in zipped format here: Kbb sky frame (600s integration): OS.20171102.48179.zip

Hbb sky frame (300s integration): OS.20171102.54008.zip

Dark frame (900s integration): OS.20171102.07749.zip

If this doesn't work, I'll email them one at a time.

[jlyke-keck]

I downloaded files 55974 and 56012, which are HD65158 in Kbb 50. I confirm the wavelength offset. By eye, BrG appears at 2.1578 micron. I also looked at Kbb 100 (19215, 19279) on HD7215 and see the same wavelength shift.

[mikekoss]

Shoot, I guess I could see two ways of fixing this. Either 1)., use another wavelength calibration from a different night, for the same configuration, and just map it to the osiris cube because it probably doesn't change too much. Presumably it must not be changing much is the reason we aren't observing arcs. or 2). try to fix with a linear offset. I am pretty hesitant about two because any arc lamp fitting usually does a non-linear fit. Not sure about OSIRIS. Has anyone ever done this?

[mikekoss]

The problem we have is one of our analysis goals is to fit the CO band heads to get a velocity dispersion, this depends critically on the wavelength calibration.

[jluastro]

There are a number of telluric absorption features in and around the CO band heads. I don’t know if they are dense or precise enough; but we have used the ESO telluric package before to fit the telluric lines with a wavelength-variable model (i.e. some kind of polynomial). This might work for you.

Cheers, Jessica

On Sep 16, 2020, at 1:01 PM, Mike Koss notifications@github.com wrote:

The problem we have is one of our analysis goals is to fit the CO band heads to get a velocity dispersion, this depends critically on the wavelength calibration.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Keck-DataReductionPipelines/OsirisDRP/issues/95#issuecomment-693634337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALEJQHWZU4T5HCYUGINTLDSGEKRTANCNFSM4QSL7QAA.

[mikekoss]

Jessica, thanks that's a good idea. I have played around with this in the optical with long slit gratings (e.g. 5500-10500), there it's really impossible to do it well because of the nonlinear wavelength corrections. But there's a lot more sky lines. @jlyke-keck @followthesheep do you know how the OSIRIS wavelength calibration in the pipeline works? Is it fitting a 1) nonlinear function for each lenselet, 2) is it doing it independently for all lenselets, 3) how often is the wavelength solution recalibrated (nightly)?

[mikekoss]

The issue I have is that for the analysis software we use (ppxf) to fit the CO bandheads velocity dispersion, it's very sensitive to issues with wavelength calibration that tend to bias the velocity dispersion (higher). But we had a very good night in 2017 (no issues), so we are trying to figure out what to do. And this data is for the first dual AGN resolved in the NIR on sub kpc scales (the 2nd if you include radio), so it's a really exciting dataset. We have an HST STIS spectra showing a dual via AGN BPT, so this data is really top priority. If we can get at a velocity dispersion, get the black hole masses, we can figure out what signal would be for a gravity wave would be. So it's a very exciting science case.

[mikekoss]

Okay, I was able to get the OH line list for the H and K-band spectra, run IRAF identify, and come up with a solution that has an rms of 0.3 Angstroms after throwing out a few blended lines. Looking at the fits cube from OSIRIS it just looks like it has a CRVAL1 and CDELT1, so it has a linear solution, for all pixels, is it really just updating that? I guess we would need to come up with a linear fit instead (so a bit higher rms).

[mikekoss]

So the results I get for the 0.05'' scale for CRVAL1 and CDELT1 are 1973.31723 | 0.2499655 compared to the original values (of 1965 and 0.25) for Kbb for 35 OH skylines. It's not terrible if you leave CDELT1 at 0.25, but you sort of have an offset of about 10 km/s between 1980 (bluer) and 2300 nm (redder). This works fairly well for two different frames spread across the night. In the H-band it looks like it's just a crdelt of 1479.205, compared to the original value 1473.

[mikekoss]

It looks like the same offset also applies to the 0.10'' data taken in Kbb. I checked some nights where we didn't have the offset, and it looks like this simple correction does about as well in terms of the STDEV of the offset from the OH lines (5 km/s) so I think it's solved. We can just update our headers for the observations affected on that night. Thanks so much for everyone's help!

[jlyke-keck]

The wavelength solution is not recalibrated very often. Generally once per thermal cycle, which can last months to years. I haven't done it yet, but will reduce other data from 2017 to see if there is variability in the wavelength solution.

[mikekoss]

@jlyke-keck Yea, this just seemed to affect this particular night and not our 2018/2019 data.