SpectroscoPyx
SpectroscoPyx copied to clipboard
PlasmaPy
Working smart
What sorts of tools and collaborations can we leverage to minimize unnecessary reproduction of effort?
Here are some that were mentioned in PlasmaPy/PlasmaPy#162 :
- MassiveOES has spectroscopy tools and is written in Python.
- Significant functionality overlap with fiasco which is specifically geared towards interfacing with CHIANTI.
- Astropy's specutils which focuses on astro spectroscopy
- Sunpy's spectra for solar physics spectroscopy
- Astropy's astroquery has many database querying tools, including ones for the NIST atomic lines database
I was just about to create an issue saying roughly the same thing.
I would also add the pyatomdb package which is an interface to the AtomDB atomic database as well as the ChiantiPy package which is the original (and still maintained) Python interface to CHIANTI.
Before writing any code, I think it best to have a well-defined scope (though of course this would change over time). It seems there are two somewhat distinct categories as far as the proposed functionality of the package:
- Parsing and interfacing with atomic databases (fiasco, atomdb, ChiantiPy) and calculating derived quantities
- Reading and manipulating spectral data (specutils, spectra)
I think a sensible approach would be to start with building the abstraction layer which uniquely defines atomic energy levels and getting that to interface with a function which is essentially a thin wrapper around astroquery. Test this for some simple cases like hydrogen and helium, where we know from the line holdings that the transition strengths and other requisite parameters are present in the NIST database. We can expand from there by testing ground state and first ionization state of higher Z elements, since those line holdings are also mostly there.
Having this basic interface in place, we can then expand in a few ways. One degree of expansion is to include interfaces to other databases under this abstraction layer. Another degree of expansion is to build a simple LTE Saha-Boltzmann spectra simulator (optically thin) which interfaces with the database query abstraction layer. A third degree would be saving database queries more permanently (in an HDF5 file) and generating a system of unique identifiers which identify the database and version. Perhaps some form of checksum and a DOI can be used to achieve this.
In parallel to all this database interfacing there is the independent task of building up functions relevant for analysis of measurements and designing diagnostics. Many of these will be low-hanging fruit (e.g., Bragg diffraction, diffraction grating, lens equations, compiling common crystals and their interlattice spacings). Others will be a bit more sophisticated (e.g., querying Henke cold filter page via HTTP, parsing the returned data, and plotting multiple filter transmissions simultaneously).
Linetools was mentioned on the astropy mailing list as having some overlaps with SpectroscoPy, but that these would be nicely complementary.
The Spectrum1D object is an astropy APE that was mentioned in the astropy mailing list. They also highlight future plans for work on astronomical spectroscopy and would welcome feedback/collaboration.
ChiantiPy and PyNeb were mentioned on the AstroPy mailing list as having potential overlaps with our project.
I just found the following packages that might also have some overlap:
I'm currently trying to use Astroquery to get some NIST data for my own project, and I have to say it kinda sucks. Looks like Astroquery caters more towards astro data than atomic data.
Yes, I'm pretty sure astroquery is intended primarily for astro-specific data. (As an aside I'd argue we should be careful of labelling it as bad for that reason - it just doesn't suit this use-case.) For atomic you're probably better off asking @wtbarnes if fiasco or one of the other packages he mentioned is able to access what you need.
@SolarDrew Alright, I'll be more precise: "The NIST interface of Astroquery kinda sucks".