[AstroPy] ESA Summer of Code in Space 2013

[Thøger Rivera-Thorsen]

On 2013-06-20 11:31, Joe Harrington wrote:
> It sounds like we're on the same wavelength (sorry) regarding the
> interface, and yes, from the state you describe writing something to
> last from the ground up or from some basic workhorse routines sounds
> like a good idea.
Nice pun ;)
As you may have seen from Adam Ginsburg, his PySpecKit actually has 
something that could provide either a starrting point or some detailed 
design inspiration (depending on how well it complies with the general 
astropy design philosophy, about which I have no idea).

>>> temperatures vs. depth.  In other words, will it calibrate the spectrum
>>> or reproduce it with a model?
>> I don't think that there is a general consensus on this, but in my view,
>> the question
>> must be which tasks make sense to do from the command line and which
>> ones will be made significantly easier
>> by means of a GUI, and implementing them in that order. I always shun
>> from software that makes me set everything through
>> point-and-click, file choosing dialogs etc., when it could be done
>> easier by CLI.
>> Reading a line list from a file should be a no-brainer from the command
>> line, and possibly, a good
>> fitting package would provide a few convenience functions for loading
>> data and line lists into the appropriate data structures.
> So, I think we're misconnecting here.  To me a line list has some
> hundreds of millions of lines, and you'd never put it in a text file.
> What kind of spectra are you thinking of fitting?  Is each feature a
> single transition, like stellar UV atomic lines, or does each feature
> integrate huge numbers of transitions, like in NIR planetary/brown dwarf
> spectra?  It sounds like you are separately fitting each feature to a
> Voigt, rather than broadening and integrating, say, all the methane
> lines, then scaling the result to the data to derive a methane column
> abundance.  Or are you thinking of both applications?  The reason it
> matters now is that some designs that do the simple situation well might
> not be easily adapted to the complex one.

Yes, seems like very different kinds of tasks we are talking about here 
- I'm doing some relatively simple galactic stellar and nebular emission 
and absorption lines, which usually are not more than maybe a couple of 
atomic transitions blended. They can show some quite complicated 
dynamics and other effects, though.

But you are right, it looks like these tasks really call for different 
approaches. Again, I think the wise thing to do is to saplit up the 
workflow in smaller tasks and evaluate one for one what would be gained 
by GUI-ifying  it, vs. what would be the cost in gained complexity of 
the interface and in sheer working hours for coding.

> FWIW, my group is working on a radiative transfer program for
> exoplanetary emission and absorption, along with a DE-MCMC fitting
> routine.  The basic RT code and MCMC are working and are OSS, though not
> yet on github.  If you do go to the point of fitting molecular spectra
> to get abundances, the RT code (written in C and depending on just the
> GSL, I think) might be what you need.  The DE-MCMC is Python (it might
> have some low-level C, I'm not sure, but if so it doesn't depend on
> anything beyond libc).  Let me know if you want these.

Did you mean the specutils project here, or me personally?
My work in the foreseeable future is probably not going to involve any 
detailed molecular fitting; we are mainly focusing on features that 
could at least in priciple be detected and distinguiished at high 
redshifts, too.




>
> --jh--
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> http://mail.scipy.org/mailman/listinfo/astropy