Master line list management

[andycasey]

We need a common method to parse in line lists from binary/ASCII formats, and then export them in different formats (e.g., latex and/or formatted for MOOG if the Python-wrapped MOOG version isn't used). This is related to #5.

A lot of this base functionality probably already exists in astropy.table, but we will need some extra functionality (e.g., checking for physically valid ranges of entries, species/element conversion, etc). And just by allowing different input formats means there are many different use cases: e.g., VALD output format with everything, or a 4-column ASCII files containing the bare-bones information for MOOG.

[alexji]

I'll write a utility for this and have the linelist in astropy format (expect it to be done by Wednesday latest). I mostly have seen MOOG linelists, do you have examples of others? Also feel free to edit the lists below.

• [x] information to store in internal data table
• [x] import MOOG format (check for loggf vs gf)
• [x] import VALD format
• [x] check for duplicate lines
• [x] export to latex list
• [x] export to MOOG

Information to store in internal table for each line: Wavelength, species, excitation potential, loggf, van der waals coefficient, dissociation energy reference for line, comment

[andycasey]

I've uploaded the GES master line list (v5) here as an example of another format. The DEPTH, SYN_FLAG and EW_FLAG are indicators for whether a line is "clean" (a subjective-yet-educated decision) or dirty.

MOOG is kind of simple in what inputs it needs, but if any other radiative transfer code were to be plugged in then they would need additional information (e.g., upper excitation potential as well as lower excitation potential, stark damping coefficient). I'm not sure whether we should include them now or not to be future-compatible with any other radiative transfer codes, or to leave that as an issue for if they are ever included. I'm inclined for the former only because it is a matter of reading in additional information if it is present (and setting nan/None if it is not), but it is up to you!

[alexji]

I wrote this in a moog-centric view, with "species" indicating element/molecule + ion + isotopes. I think I will redo it to separate them out, like the GES list. I this will make subsequent code much easier.

• [x] Determine default isotopes for elements (in moog)
• [x] Convert moog species to element(s) + ion + isotopes
• [x] Add required columns to LineList: ['numelems','elem1','isotope1','elem2','isotope2','ion']. numelems should be 1 or 2, and (elem2,isotope2) = ('',0) if no element 2.
• [x] Update LineList.hash() so instead of species it uses the new required columns (this will also avoid potential weird problems with float rounding in the isotopes that I was worried about)
• [x] Create unit tests with test linelists

[andycasey]

I have noticed that sometimes the GES list (and VALD, actually) contains isotopic information for molecular transitions, but only for one element of that molecule. For example TiO might give and isotope for Ti but show 00 for O. If this is fed directly into MOOG, it has a fit and dies. We have to make assumptions that if no isotope was given for a molecular (and atomic??!) feature then it is not ionized.

[alexji]

I pulled out the default moog atomic masses for each element and put them in for molecules if exactly one of the two isotope masses is nonzero.

[andycasey]

@alexji: Is there a way to write LineList object to MOOG format if equivalent widths are present?

At the moment I am just adding a column to a LineList table called 'equivalent_width' (units: mA) and then trying to write to MOOG format.

Also we should switch to using the astropy.table I/O registry so that we can just specify linelist.write('something.txt', format='moog'). I've implemented this here for the photospheres.

[alexji]

Yes, those are both good ideas! I'll add that shortly.