Issue with wavelength calibration

[jsbridge]

I’m trying to reduce a bit of Y-band MOSFIRE data taken earlier this month (first half of March 6). I’ve got everything installed and running, but I’m having an issue. Somewhere in the wavelength fitting something is going awry. I had only two objects in my mask. I did the interactive wavelength calibration, and it all looks fine. Then, I run the wavelength fitting for the entire slit. Finally, I apply the wavelength solution. The output file, lambda_solution_wavestack(etc).fits, looks very strange for the second object. I’ve attached a screenshot. I’m not sure where to go from here, so any help would be appreciated. I haven’t done anything weird - I’m just running the pipeline out of the box.

[joshwalawender]

@jsbridge Which mask/target was this? I'm going to download the data and look at it here.

thanks, Josh

[jsbridge]

The mask is borg_0853_new, there are only two targets in there, it’s the one called borg_0853_310_145.

On Mar 28, 2018, at 4:14 AM, Josh Walawender notifications@github.com wrote:

@jsbridge https://github.com/jsbridge Which mask/target was this? I'm going to download the data and look at it here.

thanks, Josh

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Keck-DataReductionPipelines/MosfireDRP/issues/115#issuecomment-376641771, or mute the thread https://github.com/notifications/unsubscribe-auth/AKcOqQsKrim_N1KzvRgLp51U5T_rZrPrks5tio95gaJpZM4S8NG_.

[jsbridge]

@joshwalawender Just checking to see if you've found anything on this? Thanks!

[joshwalawender]

@jsbridge Sorry for the delay. I think what is happening is that the fit for the curve of the slit is going a bit wild. This sometimes happens on longslit data and we can adjust the range of Y pixels in the fit using a keyword, but since this data is considered a MOS mask (even though it has only two slits, one of them very long), there's a slightly different code path and I don't think that option exists for this. I'm going through the code now to see what we can do. @lucarizzi have you seen this before?

[lucarizzi]

@joshwalawender @jsbridge yes I have a vague memory of having seen this before. I am downloading the data too and I will try to reproduce the error.

[joshwalawender]

@jsbridge Luca and I have been working on this and digging in to the wavelength solution code. I've made some improvements in the way the wavelength solution is propagated along the slit and this has eliminated the crazy solution you got before, but it is still not exactly right (see screenshot below).

If you want to use that version of the DRP to do a quick look (non-publication quality) examination of the results for your mask, you can grab that code from my fork of the DRP.

Another idea has been to try to reduce this data after adding Ne and/or Ar lamp cals to see if that helps the wavelength solution converge to something more sensible. I may be able to get those on Monday if you can send me the mask design file.

We'll try to look in to this further, but I wanted to give you an update on where we stand.

[jsbridge]

@joshwalawender @lucarizzi thanks for your work on this so far. I can send the mask design, should that still be useful. I tried to attach it here it didn't work so if you have an email I can send to, let me know.

[joshwalawender]

@jsbridge The next opportunity to get MOSFIRE calibrations on the telescope will be in a couple of weeks. You can send the mask design to me at mosfire_info@keck.hawaii.edu

[joshwalawender]

@jsbridge Ok, I think I've finally found a solution that works. I tried adding the arc line images, but they didn't help. I did, however, add some additional code which tries to keep the various polynomial fits from running away and I think I found a combination that works for your data.

I've attached a screen shot here of the rectified wave stack which shows nice straight lines.

You can try this to see if it works for you. Clone or download the DRP from my fork and install that version.

By default, this new code is not completely active, so after you make your driver file with mospy AutoDriver, add a line which says:

waveops['smooth'] = True

I put it right below the line which says waveops = Options.wavelength, but as long as it is somewhere above the Wavelength.fit_lambda call, it shouldn't matter.

Let me know if that works for you. I haven't tested extensively, but it did seem to work on my machine here with your data.

[jsbridge]

This looks great, thanks! I’ve rereduced the data and it looks good. I have another question, the answer to which perhaps should be obvious, but I’ll ask in any case. The final output is the 1D spectrum, but I’m more interested in seeing the 2D. Is this the *_eps.fits file? Related, I guess since I only had 2 objects, I should have made sure the length of those two slits were not epically large, as they ended up being, but I’ll admit to not totally knowing what I was doing. If the eps.fits file is indeed the final 2D spectrum, what’s the best way to isolate the region where my object is in this along the length of the slit?

Joanna

On May 4, 2018, at 12:31 AM, Josh Walawender notifications@github.com wrote:

@jsbridge https://github.com/jsbridge Ok, I think I've finally found a solution that works. I tried adding the arc line images, but they didn't help. I did, however, add some additional code which tries to keep the various polynomial fits from running away and I think I found a combination that works for your data.

I've attached a screen shot here of the rectified wave stack which shows nice straight lines.

https://user-images.githubusercontent.com/4873464/39611183-891a675c-4ef1-11e8-8648-5e2d1cc4236c.png You can try this to see if it works for you. Clone or download the DRP from my fork https://github.com/joshwalawender/MosfireDRP/tree/fix_wavelength_fit and install that version.

By default, this new code is not completely active, so after you make your driver file with mospy AutoDriver, add a line which says:

waveops['smooth'] = True

I put it right below the line which says waveops = Options.wavelength, but as long as it is somewhere above the Wavelength.fit_lambda call, it shouldn't matter.

Let me know if that works for you. I haven't tested extensively, but it did seem to work on my machine here with your data.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Keck-DataReductionPipelines/MosfireDRP/issues/115#issuecomment-386503292, or mute the thread https://github.com/notifications/unsubscribe-auth/AKcOqWUyXQKymdFbPzcbxMpARSit6X-Hks5tu9mogaJpZM4S8NG_.

[lucarizzi]

Hi Joanna I can answer that

Look at the log that the pipeline produces. It will tell you quite clearly which file is the final reduced file.

Let me know if this helps!

Luca

On May 5, 2018, at 12:21 PM, Joanna Bridge notifications@github.com wrote:

This looks great, thanks! I’ve rereduced the data and it looks good. I have another question, the answer to which perhaps should be obvious, but I’ll ask in any case. The final output is the 1D spectrum, but I’m more interested in seeing the 2D. Is this the *_eps.fits file? Related, I guess since I only had 2 objects, I should have made sure the length of those two slits were not epically large, as they ended up being, but I’ll admit to not totally knowing what I was doing. If the eps.fits file is indeed the final 2D spectrum, what’s the best way to isolate the region where my object is in this along the length of the slit?

Joanna

On May 4, 2018, at 12:31 AM, Josh Walawender notifications@github.com wrote:

@jsbridge https://github.com/jsbridge Ok, I think I've finally found a solution that works. I tried adding the arc line images, but they didn't help. I did, however, add some additional code which tries to keep the various polynomial fits from running away and I think I found a combination that works for your data.

I've attached a screen shot here of the rectified wave stack which shows nice straight lines.

https://user-images.githubusercontent.com/4873464/39611183-891a675c-4ef1-11e8-8648-5e2d1cc4236c.png You can try this to see if it works for you. Clone or download the DRP from my fork https://github.com/joshwalawender/MosfireDRP/tree/fix_wavelength_fit and install that version.

By default, this new code is not completely active, so after you make your driver file with mospy AutoDriver, add a line which says:

waveops['smooth'] = True

I put it right below the line which says waveops = Options.wavelength, but as long as it is somewhere above the Wavelength.fit_lambda call, it shouldn't matter.

Let me know if that works for you. I haven't tested extensively, but it did seem to work on my machine here with your data.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Keck-DataReductionPipelines/MosfireDRP/issues/115#issuecomment-386503292, or mute the thread https://github.com/notifications/unsubscribe-auth/AKcOqWUyXQKymdFbPzcbxMpARSit6X-Hks5tu9mogaJpZM4S8NG_.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[joshwalawender]

This fix is incorporated in to PR #118 for possible release in next major version.