Proposed new features in astropy.models

models_TODO_list

This page lists features to be added to astropy.models. It was compiled from suggestions in the initial astropy.models PR#493. Feel free to add to this list. Please make a note if you are interested in working on any of them. This list is not prioritized. 

* Add spline models and fitters.

* Write a general `Model.inverse()` method.

  This is intended to be used in models for which an analytical inverse is not available.

* Add a `CompositeModel.simplify` method, similar to AST.
 
* Add units to `parameters.Parameter`.
  
  This is necessary to support astrophysical models.

* Add support for fitting of combined models to data.

* Add support for a model language so that it's possible to do `model = model_1 + model_2`.

* Separate optimization algorithms from fit statistic.

* Add more fit statistic methods.

* Add parameter confidence intervals.

* Add model integration over bins.

* Add model convolution.

* Add symmetric errors (covariance matrix).

* Add asymmetric errors (profile likelihood).

* Make creating new simple models more user friendly. (Erik T.)

  Right now creating a model in models can be a bit complicated, as it requires overriding 
  a few different methods. Many common   models can be expressed quite easily as just a python 
  function (that accepts arrays and parameters). So I suggest creating a metaclass or possibly 
  a function decorator that can be used to build a new model class from just a single function. 
  (The sort of thing I have in mind is something like 
  http://pythonhosted.org/PyModelFit/over.html#creating-a-custom-model )

  Additionally, the documentation on creating a new model is probably a bit terse for users 
  (although maybe those more in the developer camp). So making a few more extended examples might 
  be helpful so that users can make whatever kinds of complex models they might want.

* Add astronomy-specific models.

  Currently the models in models are generally-used mathematical functions like polynomials 
  and gaussians. It would make sense to expand this to include more domain-specific "astronomy" 
  models like Sersic functions (a commonly-used galaxy surface brightness profile), NFW models 
  (used for modeling LCDM dark matter mass profiles) and similar. The suggestion from #980 might 
  make this quite a bit easier/more readable.

* Store fitter object in model object.

  In models, Fitters and their Models are separate classes. In the current version, if a Fitter 
  is applied to a model, the Model's parameters are updated, but after that (I think), the Fitter 
  is not referenced from the Model. It might be good for the Model to store a reference to the most 
  recently-used Fitter so that a user can later go back and figure out how that Model got its 
  parameters set to what they are. This might also involve storing the data used by the Fitter.