PlasmaPy
Defining scope of the project
As mentioned by @wtbarnes in #11 , we should properly define the scope of the project.
My current thinking is that the project should cover (copypasta from the current README):
- Creating a generalized syntax for describing atomic energy levels and transitions
- Creating a single interface for multiple spectroscopic databases (e.g., NIST, CHIANTI), opacity databases, and lineshape databases
- Maintaining a system of unique identifiers to precisely share and cite which databases and versions were used for a particular analysis run
- Generating tools convenient for common tasks in simulation and analysis of spectroscopic data
- Creating a spectroscopic simulation suite which can use the aforementioned interfaces to readily compare spectra generated using different databases
This falls into broad categories of:
- Querying various databases with a unified interface
- Uniquely identifying databases and versions
- Simulating spectra
- Analyzing measured spectra
Thoughts?
On the idea of unique database identifiers, one possible approach is to create a separate HDF5 file for each element for each version of each database, then archive it using a free service. I think most of these archives have a DOI or some other built-in unique identifier.
In my mind, the first two points (create generalized syntax and develop a single interface) are the most important. Using DOIs/checksums and versioning the databases in some way I think is also quite important.
One thing I worry about when it comes to providing hosted versions of these databases is that then PlasmaPy/spectroscopy effectively becomes the maintainer for that database. This perhaps is a manageable task for 1 database, but may become more cumbersome if we decided to, e.g. archive and update HDF5 versions of 4-5 different atomic databases.
There is also the issue of licensing, e.g. the CHIANTI database is not actually licensed. So would we even technically be able to archive a version of the data? I'm not sure what the story is with others (atomDB, NIST, etc.)
Yea, I'm not so keen on hosting databases either... maybe we can just test out some possible hosting scenarios, build up tools that automate most of the process, and then encourage the people who already produce and manage these databases to use our tools for creating unique identification of databases? This would require quite a bit of dialogue with the database maintainers on what they already have in place and what is feasible for them to do.
I'm not sure if this belongs in this issue or if you'd rather I make another one... But can I also suggest that there be a bit of clarification about the scope in the sense of what "kind" of spectroscopy? Ideally in the README or the description of the github repo.
That is, "spectroscopy" means a lot of different things - condensed matter physicists talk about audio "spectra" sometimes when they really mean "power spectrum". There's another python package out there that's got in its description "analysis of spectra" when what they really mean is spectral analysis of electrical signals (it's written by an electrical engineer). Similarly, specutils (as I think you know) is aimed at interoperability and analysis of astronomical spectra, specifically.
These all in principal overlap to some extent, but I think something like "SpectroscoPy is aimed first at the Atomic physics perspective but has overlap with the plasma and astronomical communities" might be a useful thing to say (if that's true! Part of why I'm leaving this comment is that I don't know exactly who the target community is).
@eteq good point! I've just updated the README. Let me know if it is clearer now.
So as a Physical Chemist, I can see a bunch of unique opportunities for a package such as this. Important spectroscopy techniques in physics and chemistry include NMR, EPR, IR, and UV-vis absorption and Flourescence. Is this project intended to support the analysis of such spectra? What capabilities is it aiming to have? (What are the nitty-gritty details?)
I see an opportunity/problem with going after EPR/NMR. To my knowledge, there is no open source package in python that allows for the quick and easy analysis of EPR/NMR spectra. EasySpin is the closest thing, but reverse engineering EasySpin is not allowed via its license.
@Haru-Fujimura I'm a specialist in plasma physics so the main things I know how to implement are in that field and basically all of our spectroscopy is atomic (molecular bonds don't really survive at our temperatures). If the techniques you are mentioning involve atomic spectroscopy then I think there could be significant overlap since the databases for atomic levels/properties should be the same or at least very similar.
I am not too familiar with molecular spectroscopy, but I expect it will be outside of the scope of this project since it involves things like vibrational and rotational modes, which I assume come from a separate set of databases and aren't trivial to calculate. Is this accurate? Can you explain what is involved in the type of spectroscopy you are interested in? (both from a modeling and a measurement perspective)
@lemmatum You are basically spot on. The only thing that we do which might correspond is Inductively coupled plasma spectroscopies: Mass Spec and Atomic Absorption.
Even if this doesn't cover NMR/EPR I would still be interested in contributing to this library for the ICP if it would feature it (Not that i am incredibly familiar with the theory at this point).
Is any one aware of libraries that are open source that do cover EPR and NMR besides easy spin?
@Haru-Fujimura Alright, so for the long term, if this project gains some traction, we might consider expanding into molecular spectroscopy. But for now I'd like to keep a limited scope so that we have achievable goals and a clean code base.
Yes there should be substantial overlap for ICP. What do you need there?
I am not aware of any EPR/NMR libraries.
We use ICP for element analysis and confirmation. Not sure if it aligns with yall's goals.
@Haru-Fujimura Not currently, but it's probably not too difficult right? Just use an atomic spectra database to match observed lines and infer which element produced those lines. Is there a quantitative aspect to it based on line intensity or width?
I am not sure at the moment. i believe we just look for characteristic absorption or emission frequencies.
Some useful resources for atomic data and spectroscopy. This includes a number of atomic databases that we could try interfacing to.