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
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.
(This refers to the models subpackage that will be in astropy when #493 is merged. The intent is to merge that without significant design changes, and address proposed updates through additional issues/PRs like this one)
My interest in this is support for WCS. From this viewpoint it would be good to have spline models and fitters. Most likely they will not use this framework (at least the fitters) so they are not going into 0.3. A lookup table model would be good too but it's not critical that it goes in 0.3.
That's where I'm coming from simply because those are packages I wrote, so they are models that I've found useful at some point or another.
But @cdeil's suggestion of paring these down sounds good to me. A number of those models (both here and in sherpa) are quite domain-specific, and hence don't necessarily belong in the core.
I've started a wiki page here and will make an initial list now.
I guess there will be lots of different opinions what kinds of models should go in, because everyone wants the models they need for their work readily available (e.g. I've never heard of the Sersic model @eteq mentioned above and probably you don't care about the exponential cutoff power law model I want).
Is a wiki page plus this issue the best solution to have this discussion?
For some models Sherpa has a "normed" variant, e.g. normgauss1d in addition to gauss1d.
The shape is the same, but the parametrization is different; for the "normed" model the amplitude parameter doesn't represent the model value at the centre, but the integral of the model. Using such a normed model in a fit has certain advantages, because typically the amplitude and extension are strongly correlated and fitting / error estimation is complicated by this correlation. Also the normed version is better suited to represent probability density functions (PDFs) like the point spread function (PSF).
So what do we want for astropy? Some options:
No normed models.
Normed models only where possible (i.e. the parametrization of the existing Gauss1DModel would be changed)
Provide both normed and "amplitude" models for some cases where the normed variant is often used like Sherpa does.
I'd like to reopen the discussion at this point, as I will work on this issue during the first two weeks of my GSoC project. So which models should be implemented in the core? Have a look at the wiki page and my work plan for a preliminary list. Any further ideas or comments?
Can I propose that we start by populating the wiki list of models that @adonath suggested? We may want to pare those down, but I would say its better to list all we want and then eliminate some that perhaps are not general enough.
EDIT: by populating I mean have people add to that list any models they think are important enough
Here's an updated wiki list of models with models not implemented in modeling yet. Feel free to update the list with models you think should go in the next version of astropy. Please include references if possible.
@bsipocz This is really only scoping out possible work. Most likely some form of this will get done but it's too early to say what exactly that will be. Good point though - I wasn't aware there is a project board for 3.0 planning. I'll update when it's a bit more clear how much of this will get done (I'm not doing the work).
Are there models still missing? If yes, do they have a specific issue for them?
As the comment above says the most useful way forward is to open issues for each and every model.
With that in mind I suggest to close this very generic issue.
Hi humans 👋 - this issue was labeled as Close? approximately 7 days ago. If you think this issue should not be closed, a maintainer should remove the Close? label - otherwise, I will close this issue in a month.
If you believe I commented on this issue incorrectly, please report this here
I'm going to close this issue as per my previous message, but if you feel that this issue should stay open, then feel free to re-open and remove the Close? label.
If this is the first time I am commenting on this issue, or if you believe I closed this issue incorrectly, please report this here
Activity
cdeil commentedon Apr 29, 2013
We should come up with a list of models we want for 0.3 ... if they are not too hard to implement I can do it.
Here's a list of models in Sherpa:
http://cxc.cfa.harvard.edu/sherpa/models/
Is there a list of models in IRAF or IDL or whatever fitting software other astronomers use?
@nden @eteq Maybe we can then go through these lists together at the upcoming models hangout and trim them down to the 20 or so most relevant.
But the restructuring and API changes should be done first before adding many models we have to maintain.
nden commentedon Apr 29, 2013
My interest in this is support for WCS. From this viewpoint it would be good to have spline models and fitters. Most likely they will not use this framework (at least the fitters) so they are not going into 0.3. A lookup table model would be good too but it's not critical that it goes in 0.3.
eteq commentedon Apr 30, 2013
Two other list of models (with substantial overlap) are at
http://pythonhosted.org/Astropysics/coremods/models.html
and
http://pythonhosted.org/PyModelFit/builtins.html#classes
That's where I'm coming from simply because those are packages I wrote, so they are models that I've found useful at some point or another.
But @cdeil's suggestion of paring these down sounds good to me. A number of those models (both here and in sherpa) are quite domain-specific, and hence don't necessarily belong in the core.
cdeil commentedon May 7, 2013
I've started a wiki page here and will make an initial list now.
I guess there will be lots of different opinions what kinds of models should go in, because everyone wants the models they need for their work readily available (e.g. I've never heard of the Sersic model @eteq mentioned above and probably you don't care about the exponential cutoff power law model I want).
Is a wiki page plus this issue the best solution to have this discussion?
cdeil commentedon May 7, 2013
For some models Sherpa has a "normed" variant, e.g. normgauss1d in addition to
gauss1d.
The shape is the same, but the parametrization is different; for the "normed" model the amplitude parameter doesn't represent the model value at the centre, but the integral of the model. Using such a normed model in a fit has certain advantages, because typically the amplitude and extension are strongly correlated and fitting / error estimation is complicated by this correlation. Also the normed version is better suited to represent probability density functions (PDFs) like the point spread function (PSF).
So what do we want for astropy? Some options:
Gauss1DModelwould be changed)adonath commentedon Jun 13, 2013
I'd like to reopen the discussion at this point, as I will work on this issue during the first two weeks of my GSoC project. So which models should be implemented in the core? Have a look at the wiki page and my work plan for a preliminary list. Any further ideas or comments?
keflavich commentedon Jun 13, 2013
If the NFW profile is going to be included, perhaps some other physically motivated models would be appropriate? I have in mind:
eteq commentedon Jun 14, 2013
Can I propose that we start by populating the wiki list of models that @adonath suggested? We may want to pare those down, but I would say its better to list all we want and then eliminate some that perhaps are not general enough.
EDIT: by populating I mean have people add to that list any models they think are important enough
nden commentedon Jul 17, 2017
Here's an updated wiki list of models with models not implemented in modeling yet. Feel free to update the list with models you think should go in the next version of astropy. Please include references if possible.
@hcferguson @eteq
(Edit): Before attempting to implement a model please state so by creating an issue. This will help avoid duplication of effort.
bsipocz commentedon Jul 17, 2017
@nden - does it mean this issue can/should be added to the "3.0 feature planning" project board?
nden commentedon Jul 17, 2017
@bsipocz This is really only scoping out possible work. Most likely some form of this will get done but it's too early to say what exactly that will be. Good point though - I wasn't aware there is a project board for 3.0 planning. I'll update when it's a bit more clear how much of this will get done (I'm not doing the work).
bsipocz commentedon Mar 18, 2019
Are there models still missing? If yes, do they have a specific issue for them?
As the comment above says the most useful way forward is to open issues for each and every model.
With that in mind I suggest to close this very generic issue.
astropy-bot commentedon Mar 25, 2019
Hi humans 👋 - this issue was labeled as Close? approximately 7 days ago. If you think this issue should not be closed, a maintainer should remove the Close? label - otherwise, I will close this issue in a month.
If you believe I commented on this issue incorrectly, please report this here
astropy-bot commentedon Apr 27, 2019
I'm going to close this issue as per my previous message, but if you feel that this issue should stay open, then feel free to re-open and remove the Close? label.
If this is the first time I am commenting on this issue, or if you believe I closed this issue incorrectly, please report this here