Instrument Packs: What Information (and Format)

[jdtsmith]

What features of the model framework should live in separate instrument packs? I can imagine:

• Wavelength cutoffs
• Resolution vs. wavelength (which may be a model, e.g. a polynomial fit), and may be disjoint.
• Weighting parameters to de-weight cruddy ends of segments.

But what if you want to blend spectra together from multiple intstruments?

We could obviously go much further to correct response function issues, etc., but PAHFIT is not a calibration or reduction tool.

[jdtsmith]

We should probably adopt the same/similar format as for our science model packs.

[els1]

I'm in favour for allowing blend spectra, e.g. Spitzer SL and SH combined.

[jdtsmith]

I sometime wonder if PAHFIT itself should be handling the blending, or just allow inputing as many spectral segments as you want, and adapt the model accordingly.

[karllark]

I think that we should keep the spectra separate. This makes it much easier to create the correct model.

Going a bit further, I think we should keep the spectral segments from the same instrument separate. Thinking about this for MIRI, there will be 12 grating settings to get the full 5-28 um spectrum. Merging them will be possible, but it will be conceptually easier to get the right instrument resolution for each segment if we just keep the separate. Nothing in the fitting that requires a merged spectrum.

And this would allow for possibly adding in the appropriate parameters to solve for the offsets between the segments as part of the PAHFIT fitting. Better uncertainties as the fits to the features would then include the uncertainties on merging the spectra.

[jdtsmith]

The reality of spectral stitching is that it's a distinct task from model fitting, since it relies on deep (and usually hard fought) intrinsic knowledge of artifacts. Often the spectra where they overlap don't just fail to match in level, but have different slopes, apparent features in one missing in the other, etc. It takes some skill to know how far out to trust individual spectra segments, and which to trust where they overlap. Compounding this is that the ends of orders/detectors are often the most poorly calibrated. We have to decide how much such pre-existing knowledge to inject into the instrument packs. My feeling is we shouldn't go too far: that's not the business we're in, and calibrations can change and improve, and artifacts can vary with S/N.

For science results, carefully blended spectra are expected. But perhaps we can keep it an option to input a bunch of spectral segments, possibly even with priors softening the weighting at the ends of the segments. In fact, as you mention, this is quite a bit cleaner in terms of mapping an instrument pack to a given spectra segment.

[jdtsmith]

Honestly, I'd love to see an astropy module that just handles spectra stitching. We have a vast collection of algorithms for IRS(+Akari), but they aren't really externally consumable.

[karllark]

Spectral stitching sounds like a astropy affiliated package idea to me. Or maybe part of the specutils package?

https://specutils.readthedocs.io/en/latest/

[els1]

In class InstPackSpitzerIRSSLLL, in def__init__, there is a typo: self.instrumet instead of self.instrument

[karllark]

@els1: thanks for the typo notice, I'll fix this in the current big PR (#51).

[jdtsmith]

Instrument pack and stitched spectra now handled by #226 & #233.