You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A jointly fitted feature (line, practically) can apply to more than one segment. Model decides which segments, just as it decides which lines to "cull" (i.e. no segments).
If a list of spectra is given for fit, Model first checks if the fitter has the JointFit capability, raises PAHFITCapabilityError if not.
If so, Fitter.fit (and others) will have to accept a list of numpy arrays for its wavelength argument.
Model informs Fitter of the joint fit via a special keyword to add_feature_line (etc., should we choose to do this for other feature kinds) — e.g. segments — which provides a tuple of segment indices (often, just one) to which this feature applies.
In this scenario, if the user has hard-coded line fwhm into the table (or tied it to another parameter), an error is thrown — a joint fit makes no sense except when the instrument pack is controlling.
Fitter does what it needs to do to arrange for a joint fit for that feature. When it is queried for the fit results for that feature, it must return a single best-fit value for power. The value return for fwhm is ignored (and probably shouldn't actually be returned unless it was actually fit, i.e. not in this scenario).
Let's discuss here the logic of how multi-segment fitting can/will go, now that we have abstracted out
Fitter
and its spoon-feeding parentModel
.The text was updated successfully, but these errors were encountered: