For those who might not be aware, the idea to add this work to astropy came out of a discussion at the coordination meeting, and is a necessary step for the "generalized" WCS project. But It also should be very useful as a model-fitting interface that can be shared throughout astropy.

@nden - just for information, I do plan to take a careful look at this, but it will be easier once 0.2 is out of the door. But at first glance, this looks great! I wonder whether it would already be worth isolating the WCS-specific stuff to astropy.models.wcs for clarity?

@astrofrog - I am going to push changes to master soon - mostly related to moving constraints from fitters to models, you may want to wait for this.
The only strictly WCS-specific modules so far are projections.py and rotations.py but models in models.py can be useful for WCS too. Since init.py will import all modules from models and models.wcs, then I'm OK with splitting them, since I won't have to remember where a specific module lives.

@nden - sorry, I have been tied up with other things and haven't been able to look at these changes closely. From the comments and commit titles it looks like you made some changes that I'll like. 😃 When things are quieter next week I'll get back to this.

@nden You commented here that you plan to

- Separate optimization methods form fit statistic
- Add parameter confidence intervals

It's not clear to me what the proper home for the fit statistics, optimization methods and confidence interval methods is. E.g. in Sherpa each has it's own sub-package (see here):

• stats (fit statistics like various Likelihoods and Chi2 functions, see here)
• optmethods (optimisation methods, see here
• estmethods (confidence limit estimation methods, e.g. profile likelihood)

I think the fit statistics should go in astropy.stats, actually I'm implementing the Sherpa statistics (and other stats things) at the moment:
https://github.com/astropy/astropy/wiki/What-methods-do-we-want-in-astropy.stats%3F
https://groups.google.com/d/topic/astropy-dev/Zwgafam171E/discussion

Where the optimisers and confidence interval methods (well, at the moment the wrappers around scipy.optimize, not the actual implementations) should live is not clear to me. E.g. the Rolke method I propose to include in astropy.stats is really just a special case of the profile likelihood method. I guess they could go in a new astropy.optimize package or into one of the existing astropy.utils or astropy.stats or astropy.models packages, although in the astropy.models case maybe renaming it to astropy.fitting would be better, because e.g. I only expect to find models in astropy.models. Anyways, this is "just" naming, and I don't have a strong opinion what we should do, I just wanted to mention the question here.

I'm very interesting in using the astropy modeling tools, so if and when this gets merged, I'll work on a tutorial for it based on blackbody fitting - I'd like to translate this: https://code.google.com/p/agpy/source/browse/trunk/agpy/blackbody.py to astropy, so that it uses astropy's units framework + fitting framework.

But keeping the linked example in mind, I think it would be worthwhile to make "mpfit to astropy.models" and "lmfit-py to astropy.models" guides. I haven't looked at the PR closely yet, but I'd really like to know how it differs from https://github.com/newville/lmfit-py.

@keflavich It seems this is similar to lmfit-py in many ways. I think the main difference is that we have a formalized Model class and the Parameters (functionally similar to lmfit-py.Parameters) is attached to it but shared between models and fitters. This makes it possible to create composite models. astropy.models supports the same constraints, although after looking at lmfit-py I see that the bounds are calculated in a different way. It probably differs in other details as well. Also, the goal in astropy.models is to create a formal separation of optimization methods and statistics methods so that they can be combined arbitrarily.
I looked briefly at blackbody.py and I think it should be straightforward to convert it to astropy.models.

@cdeil Sorry for not responding for such a long time - I was working on other things while waiting for the 0.2 release and this fell through the cracks.

Having separate astropy subpackages for optimization, statistics and estimation methods may make sense in the future. But I think we should try to avoid package proliferation unless necessary. If code functionality is used by several packages it may make sense to separate it. I am not too happy about the name too but I can't come up with a better one. The initial name was "fitting" but at the last coordination meeting it was decided to rename it to "models". I have no strong feeling either way.

@taldcroft - can you review this in the near future to see if it addresses your concerns?

I'll also review this within the next week.

@astrofrog - I'll plan to review this within the next week as well.

What is the next step in this painful process of getting the PR merged?

The documentation build on Travis fails because of 2 warnings. Is this what's holding off the merge? If so, I've already asked but will ask again, if someone familiar with the sphinx extensions, can tell where the warnings are coming from.

None:1: WARNING: citation not found: R7
None:1: WARNING: citation not found: R8

Ooh, this was a tricky one @nden - the problem was that in a couple places you had references in your docstrings that were used in the first sentence of the docstring. Because automodapi uses the first sentence to populate the function/class table, it was pulling those references into the table... but the references in question weren't in the page the table is on, so it couldn't find a citation.

Anyway, I think I got it to work by just moving the references to a new sentence (e.g., eteq@models#L1R976) - I've got them running in travis now on my branch, and assuming they pass, I will go ahead and merge this.

So hopefully no more steps!

Merged! Thanks for all your effort on this @nden! Sorry again that it has taken so long.

I'm looking forward to playing around with this! Good Job!

@eteq Thanks for figuring out the problem with the references, I was lost.
I'm looking forward to comments about its functionality as others try it out.

@nden - thank you for all your work on this, this will be a great addition to Astropy!

I'm thinking maybe this should be advertised on astropy-dev now so that people who keep up with the latest dev version can play with it and report any issues?

@astrofrog Good idea! It's best if this is tested as much as possible before it is released. Would you like to send a note or do you want me to do it?

Cool - I can send a note to the list!