Abstract fitter API draft

[drvdputt]

As discussed in #257 I abstracted out parts from my new model builder branch. This abstract API describes what I need to keep the current astropy fitting implementation working.

@jdtsmith Let's see if my idea is compatible with your new fitter.

Note that only the fitter.py file was added. This API is not used by any other code yet. Model is still using the astropy fitting framework directly. All of the astropy compound model machinery should be moved to a subclass of Fitter called APFitter, after which Model will be simplified, while preserving the original behavior.

[jdtsmith]

Great, thanks Dries, very interested to iterate on this with you. I'm dreadfully busy for two and half weeks. I'll be in Baltimore early next month maybe we could find 30min to sit down with it.

[jdtsmith]

I think it's important to implement the raw calls to all the explicit model components which represent some feature in this ABC. E.g. blackbody (perhaps with a modified keyword), drude, gaussian, etc. These would have standardized units for both input and output that all Fitters would have to respect, and external callers (like Model) can then do their own decomposition quite easily. E.g. tabulate could live outside, and simply examine all/subsets of the features and compose them together. E.g. the user asks for "all continuum components", Model can go through and call the relevant fitter blackbody (with and without modified), accumulate the results, and return the continuum-only model to the user. Or similarly for subsets, like "all lines in the set called h2_lines", etc. (of course using the in-built astropy.Table capabilities to save re-building the wheel).

[jdtsmith]

Is this superseded by #289 and therefore should be closed?

[drvdputt]

Yes, that is correct. I can close it myself.