Skip to content

Add astronomy-specific models #981

Closed

Description

@eteq

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)

Activity

  1. cdeil commented on Apr 29, 2013

    @cdeil
    Member

    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.

  2. nden commented on Apr 29, 2013

    @nden
    Contributor

    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.

  3. eteq commented on Apr 30, 2013

    @eteq
    MemberAuthor

    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.

  4. cdeil commented on May 7, 2013

    @cdeil
    Member

    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?

  5. cdeil commented on May 7, 2013

    @cdeil
    Member

    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.
  6. adonath commented on Jun 13, 2013

    @adonath
    Member

    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?

  7. keflavich commented on Jun 13, 2013

    @keflavich
    Contributor
  8. eteq commented on Jun 14, 2013

    @eteq
    MemberAuthor

    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

  9. nden commented on Jul 17, 2017

    @nden
    Contributor

    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.

  10. bsipocz commented on Jul 17, 2017

    @bsipocz
    Member

    @nden - does it mean this issue can/should be added to the "3.0 feature planning" project board?

  11. nden commented on Jul 17, 2017

    @nden
    Contributor

    @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).

  12. bsipocz commented on Mar 18, 2019

    @bsipocz
    Member

    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.

  13. added
    Close?Tell stale bot that this issue/PR is stale
    on Mar 18, 2019
  14. astropy-bot commented on Mar 25, 2019

    @astropy-bot

    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

  15. astropy-bot commented on Apr 27, 2019

    @astropy-bot

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions