search

PAHFIT / pahfit

Model Decomposition for Near- to Mid-Infrared Spectroscopy of Astronomical Sources
https://pahfit.readthedocs.io/
18 stars 26 forks source link

Introduce sigma_v + v_off, and remove line FWHM as a user-settable parameter #293

Open jdtsmith opened 4 months ago

jdtsmith commented 4 months ago

A real ambiguity regarding the Model -> Features interface is what type of data is returned back into the Features table. The most principled approach is to return only details of the scientific model. The FWHM of a line is not such a detail.

Rather than letting users set that for unresolved lines, and having Model populate it after fit, it would be a cleaner approach if lines (and dust features) allowed an optional sigma_v (in km/s). sigma_v (default units: km/s) represents additional line width above and beyond that of the (Gaussian) instrumental line profile.

There are some details about applying sigma_v, but it's by far then the cleanest approach: all Features tables remain "unsullied" by artifacts of the instrumentation, and can hence be applied to any spectrum(/a) you throw at it (as long as they have valid instrument information)

Then fit, tabulate, plot, etc. would not need a way to "override the instrument". They are always applying instrument details of the plotted/tabulated/fitted spectrum(/a).

jdtsmith commented 4 months ago

Couple of issues: in some systems it might be necessary to allow a "forked" line with both a sigma_v and a v_off. I.e. you'd have a core line at the systemic velocity, and then a broadened component, at a slight shifted velocity. This should be highly constrained to work at all.

One issue this brings up: Fitter will need to know the instrument resolution for both these features, since it will be adding the underlying resolution in quadrature with the physical broadening term. It may be challenging to keep Fitter entirely out of the instrument game, because some instrument knowledge will be needed within the fit function itself.

jdtsmith commented 4 months ago

Thinking again, maybe Fitter only needs to know the (initial) central instrument resolution for lines, which it will already be getting, and sigma_v would just presume resolution is ~fixed over reasonable ranges of velocity spread and offset. For (narrow) Drude bands, we could also provide the internal Fitter set_feature_drude the same resolution (i.e. if it were a line).

Note that the Sara Profile remapping (#288) would happen generically at the Model level; if the science pack for some feature asks for, say 0.1–0.15µm, we'd know the "real" range to explore is 0.121-0.173µm (or whatever), and instruct our Fitter to use that range with the SaraProfile component.

It's much easier to reason if we assume features are ~fixed in instrument resolution even as they are varied.