Reading in the IGRINS Wavelength solution

[kfkaplan]

Hi Everyone,

I am currently poking around the muler IGRINS code and when I went to read in a reduced IGRINS spectrum, I realized it is trying to read the wavelength solution from the same reduced spectrum but that .spec.fits file had no wavelength solution in it. I am using the latest version of the IGRINS pipeline (from 2017) which will generate wavelength solutions for sky OH or standard star A0V spectra but the pipeline products outputted for these are seperate from the science targets. The .spec.fits files for my science targets do not have the WAVELENGTH keyword. Am I missing a step here or is there some updated version of the IGRINS pipeline I am unaware of? If not, I would like to modify the IGRINSSpectrum class to be able to include an option to read in a second file for the wavelength solution.

-Kyle

[gully]

Hi Kyle, I believe muler currently only supports reading in the pipeline products that end in spec_A0V, it appears you are attempting to use a prior step in the plp. We would welcome contributions to support additional plp output data columns. One way to do that would be to mimic the "ancillary_data" approach for that HPF uses for the sky fiber data. Whatever approach you consider, it should have a fallback plan in case those spectra are not available (see what we currently do for the sn.fits files for IGRINS).

[kfkaplan]

Hi Gully, Thanks for the explanation. I see what is going on now. I think the best approach in this case is to have the IGRINSSpectrum and IGRINSSpectrumList classes accept both .spec.fits or .spec_A0V.fits flies and act accordingly depending on the filename. In the case a .spec.fits input is detected, an argument named wavefile=something.fits will need to be specified. This is for the .wave.fits or .wvlsol_v1.fits outputted by the IGRINS pipeline so the user can pick their desired wavelength solution. Does this all sounds good?

[gully]

Hi Kyle, exactly! Yes, I would be in favor of supporting additional plp modes. I would recommend the least amount of user intervention as possible, so in regards to your additional keyword:

In the case a .spec.fits input is detected, an argument named wavefile=something.fits will need to be specified.

does the wavefile always share the a common file basename or "stem" as the .spec.fits file? If so, the default behavior should be to search for such a file in the same directory as the spec.fits file. If there are scenarios where that structure/assumption is too rigid, then a fallback to providing a wavefile=None ➡️ wavefile=something.fits could be considered.

[kfkaplan]

The wavefile does not share a common base name with the .spec.fits file since the wavefile is generated from an A0V standard or OH sky file which starts with a different frame number than the target. Currently I have it set so that the default is you don't put in wavefile (wavefile=None) and the code assumes your science target file is a .spec_a0v.fits. If you put in a wavefile, the code will assume your science file is a .spec.fits file instead. In other words, it is pretty much as you suggest.

[gully]

So the wavefile will share the same night, and if there are multiple wavefiles per night one could automatically check the timestamp for the closest in time. The spec_A0V file also should have a fits header keyword for the file index of the A0V file used for the telluric correction. So if that basename is common to the wavefile (or fits header info), then you could conduct the matching and therefore not require wavefile= keyword.

I recommend if it all possible to implement this automatic matching base on night, time difference, or header keywords, because it is one less requirement on the user.

[kfkaplan]

I intended the wavefile to just be something the user will select, and 90% of the time will be generated from the A0V star taken for their target which they should know. You want something that most closely resembles the pointing of the telescope and rotation of the instrument on the target, due to flexure. I would be weary of trying to match timestamps as that is not always a reliable way to select what might be best for the wavelength solution, although it might be "good enough" in most cases if you are not doing velocity work.

[gully]

Ah, ok, so it's not feasible to reverse engineer the matching. That's a shame! It is best to add it as a kwarg, then, as we worked out above, with all the provisos. I'd be happy to review a Pull Request for this or other features. If you need to add example data, consider adding it here, again as a Pull Request: https://github.com/OttoStruve/muler_example_data

[kfkaplan]

Yeah I think it would be best not to automate that. The user should know their science target, their standard star, and what they want to use for their wavelength solution. Everything else can be automated.

I've pushed my changes as a pull request and will upload (as a pull request) some example data later today so others can test.

[kfkaplan]

I think this is a good place to continue our discussion of the .spec_A0V.fits files. My understanding is that these files are generated by the divide-a0v command in the IGRINS pipeline (see: https://github.com/igrins/plp/wiki/Plotting-spectra-&-divide-by-A0V). This task does a simple relative flux calibration + telluric correction with the A0V standard star spectrum and the synthetic Vega spectrum that is built into the pipeline, but was not really intended to be the "final" output of the IGRINS pipeline. It might be good enough for some science applications, but the "final" output should be the .spec.fits files. This is why I added the ability to read them in along with the .wavelength.fits flies (to pull in the wavelength calibration).

I am guessing that you have been using a script that runs the divide-a0v task as a last step when running the IGRINS pipeline.

Personally I think the user should do a more careful relative flux calibration + telluric correction themselves using the standard star spectrum akin to what you do in the following tutorial: https://github.com/OttoStruve/muler/blob/main/docs/tutorials/telluric_correction_with_gollum.ipynb or at least be given the option (hence my additions to igrins.py). This allows finer control of standard star line broadening, stellar type, line of sight velocities, Galactic reddening by dust, ect.

Let me know what your thoughts are, or if I am overlooking something about .spec_A0V.fits.

[kfkaplan]

Issue was resolved long ago. Muler reads in both types of wavelength solutions. User can decide which they prefer.