[AstroPy] unsubscribe

[Matt Stoeckel]

On 6/20/13 4:37 PM, astropy-request at scipy.org wrote:
> Send AstroPy mailing list submissions to
> 	astropy at scipy.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://mail.scipy.org/mailman/listinfo/astropy
> or, via email, send a message with subject or body 'help' to
> 	astropy-request at scipy.org
>
> You can reach the person managing the list at
> 	astropy-owner at scipy.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of AstroPy digest..."
>
>
> Today's Topics:
>
>    1. Re: ESA Summer of Code in Space 2013 (Th?ger Emil Rivera-Thorsen)
>    2. Re: specutils, pyspeckit, etc. (Adam)
>    3. Specutils / Duplication of Effort (Adam)
>    4. Re: AstroPy Digest, Vol 81, Issue 12 (Th?ger Emil Rivera-Thorsen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 20 Jun 2013 23:24:14 +0200
> From: Th?ger Emil Rivera-Thorsen  <thoger.emil at gmail.com>
> Subject: Re: [AstroPy] ESA Summer of Code in Space 2013
> To: astropy at scipy.org
> Message-ID: <51C372FE.8090501 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 20-06-2013 18:27, Erik Tollerud wrote:
>> I want to issue a generic plea on this issue: lets do our best to join
>> forces.
> I think everyone has agreed that the specutils should be an affiliated 
> package, resting as heavily as possible on astropy core.
>
>> There are already a number of tools that do part of spectrum
>> plotting and line-fitting, and if we'd all work together, with less
>> effort we'd have a tool that does all of those and more.   That's the
>> main point of Astropy, after all: encouraging collobaration on and
>> re-use of python tools for astronomy.  I'm partly guilty here, as I
>> have a similar fitting tool in astropysics -
>> http://pythonhosted.org/Astropysics/gui/spylot.html, but I'd rather
>> encourage people to use a tool that we can all get behind. I'll  call
>> this the "Astropy spirit" :)
> I have tried spylot myself and liked it, but it didn't match my needs 
> and I found it easier to code my own thing than modify yours, which I 
> actually considered. But I think that the idea has resonated so well is 
> exactly that many of us have made an effort to create something, but 
> kinda-sorta only made it halfway to something generally usable. That 
> gives us a lot of design ideas floating around and a lot of coding and 
> designing experience to exchange, but I believe the wise thing to do 
> would be to build something simple but modular and extensible that 
> integrates well with and makes strong use of astropy core. So I believe 
> we are actually on the same page here.
>
>
>> That said, I see the virtue of designing a new tool (ideally an
>> astropy affiliated package) to combine the shared wisdom (perhaps with
>> SOCIS, if it goes through). But the *worst* thing to have happen is to
>> have the other efforts continue in parallel, with everyone designing
>> similar but slightly incompatible tools.
> We shall not disagree about that point, either!
>
>> Along similar lines, Emil and Adam (although I think Adam already
>> knows about it), I'd *strongly* encourage you to take a look at the
>> astropy modeling framework
>> (http://docs.astropy.org/en/latest/modeling/index.html) - this will be
>> in the next major release, and I'd hate to see you re-implementing all
>> of that in an incompatible way. Or, if you don't like something about
>> how that works for your needs, please help us make it better!
> I am more discussing design and not going to be much of a coding work 
> horse, as my summer and fall is quite swamped - but again, I completely 
> agree and it is also my impression that this was the general consensus 
> between anyone who's shown interest in the project.
>
> I am, however, going to continue working on my own personal app, since 
> it is highly specialized and I am tayloring it for a specific science 
> project and I think chances are low that astropy will be usable for that 
> within the time frame I need. But while writing it, there are also some 
> more common functionality that I have written into it that could 
> possibly be useful for an astropy affiliated package - e.g. a Traits GUI 
> for interactively building compound lie profiles.
>
> Cheers,
> Emil
>
>> On Thu, Jun 20, 2013 at 8:42 AM, Slavin, Jonathan
>> <jslavin at cfa.harvard.edu> wrote:
>>> Hi Adam,
>>>
>>> I have used pyspeckit.  There are parts of it that are very useful, but I
>>> found overall that it didn't do what I wanted.  For example, I wanted to
>>> give it my spectrum, have it display it, allow me to manually (in the gui)
>>> place my guesses for line centers (would probably need guesses for widths as
>>> well) and then fit the lines (and continuum) and return the fitted line
>>> centers, widths, and amplitudes, etc. along with error estimates.  It's been
>>> a while now since I used it, but as I recall, pyspeckit did not do all of
>>> those things.  There may have been other reasons as well, but in the end I
>>> wrote my own fitting routines to work with the data.  Am I wrong about the
>>> capabilities of pyspeckit?
>>>
>>> Jon
>>> ________________________________________________________
>>> Jonathan D. Slavin                 Harvard-Smithsonian CfA
>>> jslavin at cfa.harvard.edu       60 Garden Street, MS 83
>>> phone: (617) 496-7981       Cambridge, MA 02138-1516
>>> fax: (617) 496-7577            USA
>>> ________________________________________________________
>>>
>>>
>>>
>>> On Wed, Jun 19, 2013 at 5:21 PM, <astropy-request at scipy.org> wrote:
>>>> Date: Wed, 19 Jun 2013 13:32:31 -0700 (PDT)
>>>> From: Adam Ginsburg <keflavich at gmail.com>
>>>> Subject: Re: [AstroPy] ESA Summer of Code in Space 2013
>>>> To: astropy-dev at googlegroups.com
>>>> Cc: astropy at scipy.org
>>>> Message-ID: <44536fa7-b34e-4f05-941b-2cc05535bcc5 at googlegroups.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>>
>>>> Emil and Jon - there is a package that fits exactly those requirements,
>>>> called pyspeckit:
>>>> pyspeckit.bitbucket.org
>>>>
>>>> One of my major goals over the next year is to incorporate it into astropy
>>>> bit by bit, i.e. make it work with astropy.models, astropy.units, and
>>>> specutils.  Only a little progress in that direction has been made (in
>>>> part
>>>> because my coding efforts have been focused more on astroquery).
>>>>
>>>> Emil - there is a scipy-dependent voigt profile implemented in pyspeckit.
>>>>   You can check that it agrees with yours:
>>>>
>>>> http://pyspeckit.bitbucket.org/html/sphinx/models.html#pyspeckit.spectrum.models.inherited_voigtfitter.voigt
>>>>
>>>> I'm bringing this up on this particular thread because I had considered
>>>> submitting pyspeckit as a SOCIS project, but I think focusing on specutils
>>>> instead will be better for the community.  Nonetheless, there are some
>>>> specific project ideas in place that may help support the case for a
>>>> student working on specutils via SOCIS:
>>>> pyspeckit.bitbucket.org/html/sphinx/projects.html
>>>>
>>> _______________________________________________
>>> AstroPy mailing list
>>> AstroPy at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/astropy
>>>
>>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 20 Jun 2013 15:26:04 -0600
> From: Adam <keflavich at gmail.com>
> Subject: Re: [AstroPy] specutils, pyspeckit, etc.
> To: astropy at scipy.org
> Message-ID:
> 	<CAEBNSwZ2uJrxwREAUg4y0zQBD5U91dGFCsYvV4QtEc7S6qG+Lg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> (apologies for the subject and my delay in replying, I have been
> receiving astropy-users e-mails in digest form and have missed nearly
> everything.  So this e-mail is also a vote to move to
> astropy-users at google)
>
> As Erik said, it's best to merge these parallel efforts and try to
> develop one common package with a nice interface.  My vision for the
> future of pyspeckit is essentially to have it be a wrapper of
> specutils + astropy.models + astropy.units, and in fact my current
> coding effort is mostly going in that direction (see, e.g.,
> spectroscopic equivalencies in astropy).  I wanted to raise it as an
> example of something that works *right now*, but doesn't work
> perfectly (as Jonathan rightly pointed out).  Most of the models
> implemented in pyspeckit should be very easy to re-write as
> astropy.models... models.  That goal, in particular, is a big
> component of one of the specutils SOCIS proposed projects.
>
> Also, pyspeckit's frontend is matplotlib-only, which is slow but
> compatible with everything.  Because it's matplotlib-only, and
> matplotlib doesn't have a ton of GUI features (more than you'd think,
> fewer than you need), the GUI side is very IRAF-splot-like.
>
> Re: Jonathan - pyspeckit does all those things.  If you want them
> interactively, have a look at this example:
> pyspeckit.readthedocs.org/en/latest/interactive.html
> That said, the GUI interface really is not the best - it's not what I
> want, but it is what is possible with matplotlib right now.  A
> summer-of-code student could, I think, turn my half-assed GUI into a
> real one (for specutils).  If anything in particular is missing that
> you *really* want, though, I'm happy to try to support it in pyspeckit
> now, with the idea of porting it to specutils once things come
> together.
>
> Re: Kelle - I think pyspeckit can do anything splot can at this point,
> though I'm not so sure about spectral indices.  Ratios should be
> easy...
>
> I think there is a lot to be learned from pyspeckit (and Erik's
> pymodelfit/astropysics) when developing specutils, some of which will
> just be "lessons learned" (GUI features?) but other components that
> can really be reused code (especially the models).
>