PlasmaPy / SpectroscoPyx

A community developed python package for spectroscopy.
Other
42 stars 12 forks source link

Working smart #11

Open lemmatum opened 6 years ago

lemmatum commented 6 years ago

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 :

wtbarnes commented 6 years ago

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:

lemmatum commented 6 years ago

@wtbarnes , I've opened #13 for a discussion on project scope.

lemmatum commented 6 years ago

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

lemmatum commented 6 years ago

Linetools was mentioned on the astropy mailing list as having some overlaps with SpectroscoPy, but that these would be nicely complementary.

lemmatum commented 6 years ago

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.

lemmatum commented 6 years ago

ChiantiPy and PyNeb were mentioned on the AstroPy mailing list as having potential overlaps with our project.

namurphy commented 6 years ago

I just found the following packages that might also have some overlap:

lemmatum commented 6 years ago

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.

SolarDrew commented 6 years ago

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.

lemmatum commented 6 years ago

@SolarDrew Alright, I'll be more precise: "The NIST interface of Astroquery kinda sucks".