Supporting both single-segment and merged multi-segment data

[drvdputt]

The new paradigm uses instrument packs that define FWHM etc of a single segment. But we still expect many users to only have merged spectral data (or even, it might take a while until we get the 'separate segments' type of fitting to work). The changes in #222 (integrated from #229 ) have introduced a concept of a 'merged' instrument model. Lines in the overlap regions are given a variable width, while lines covered by a unique instrument segment have fixed widths that are defined by the instrument pack.

After todays discussion, we came across separate but related challenges that come with this.

1. What if the observed data provided by the user do not match the instrument specification? The data could be a little bit out of range (i.e. due to new wavelength calibrations), or large (the user specifies the wrong instrument model)
2. How do we decide which lines to keep, when translating a feature list into a fittable model. Currently, we check the parameters of the instrument model(s). But we should also allow users to provide data with a different range, i.e. only partly covered by the specified instrument segments.
3. We want to allow merged, but disjoint spectra. E.g. only MIRI ch1 and ch3, with a gap in between.

After some discussion, a workable way is as follows:

• Trim the feature list according to the given data, not according to the range specified by the instrument model.
• We will allow some leniency in terms of data range vs instrument range. The data can inside the range, or slightly outside. In the latter case, the FWHM model for the instrument will be extrapolated, and we will issue a warning. If the difference between the provided wavelength range and the instrument list is very large, we will throw an error and stop the program.

[jdtsmith]

Great summary @drvdputt. Do we think this functionality should live in instrument.py? Seems sensible to be able to pass the user-supplied spectral-range as an optional parameter, check it for the "lenient warning" or error, then proceed to use its values as the min/max range for hard or "near_fwhm" based cutoffs. This avoid repeating the logic twice: one for the instrument pack configured coverage range, and again for the actual user-supplied coverage. Thoughts?

[drvdputt]

Yes that sounds reasonable. The instrument module checks if the range given by the user is reasonable with respect to the instrument, and will decide if we quit, or continue using the given data. Something likeinstrument.validate_wave_grid(segments, wave_micron). After that point, it is assumed that the data are OK, and we can to the feature trimming based on the wavelength range from the data.

Not sure how we are going to handle the disjoint case though. Need a way to identify the gap in the wavelength grid, and drop features based on that (if we don't use the information about the instrument).

Perhaps this is solvable if we figure out the right thing to do in validate_wave_grid(), and provide a return value containing the ranges where we want our features. Something like ((start, stop), (start, stop)) pairs, that tell you where the instrument model and the given wavelength grid overlap, and therefore which features we want to keep.

[jdtsmith]

This is now supported with glob-style instrument specification, and the (mandatory) instrument.check_range function.