fiasco should be reorganized around the astropy-helpers submodule for packaging, docs, and test infrastructure.

The ionization equilibrium calculation uses the SVD to compute solutions to the homogeneous linear system of equations. For this to be applicable, the matrix composed of ionization and recombination rates must be singular (i.e. det(A)=0). If not, an error should be raised.

There are currently no tests. There should be. For everything.

The indices used to denote the different energy levels in the *.elvlc files start at 1. Shifting them all down by 1 (so that they start at 0) when the database is formatted into HDF5 would make it easier to iterate over levels and transitions and index. Alternatively, this can just be done in the interface.

Currently, ion objects can only be created using Arabic numerals, e.g.

import fiasco
fiasco.IonBase('Fe 5')
fiasco.IonBase('Fe +4')

Given that ions are commonly denoted using roman numerals, i.e. Fe V is Fe 5 or Fe +4, it would be nice to be able create ions as

fiasco.IonBase('Fe V')

Since fiasco is Python-3-only, we can use function annotations when requiring specific units on inputs. See astropy quantity docs for more info

Hi

Just out of curiosity,
Should density for radiative loss be able to handle kg/m^3 not just m^3?

Second suggestion---- include a tutorial to have just installation with an anaconda virtual environment. Using Python 3.6 with other Pythons were causing issues with my Ubuntu.

Thanks

Somewhere in the level populations calculation (or a function that is called in that calculation), units are stripped off of temperature without making sure it is converted to K. Thus, passing in temperature in units other than K gives the wrong answer.

Probably need to write some tests to check that methods give same answers (regardless of units of input) to make sure this does not happen again.

The Travis config file is needlessly complicated and could be greatly simplified. See this example

As part of a reorganization of PlasmaPy subpackages, we decided to rename plasmapy.atomic to plasmapy.particles. This change is in part because the subpackage includes data and representations for a bunch of different fundamental particles and should eventually include custom particles, so "atomic" wasn't broad enough. Once we release version 0.3.0, I'll try to remember to submit a PR here to unbreak what we have broken.

Relevant PR: PlasmaPy/PlasmaPy#742
Future package structure described here: PlasmaPy/PlasmaPy-PLEPs#26

Currently, you can create ions like,

>>> import fiasco; import astropy.units as u
>>> foo = fiasco.Ion('H 500', [1e6]*u.K)

and no error will be raised (until of course you try to access data). Obviously this is nonsense since there is no ionization state past H II (or H +1), fully ionized hydrogen.

A few questions:

• Should we check for stage <= Z+1 and raise an error if not satisfied?
• Should we check the database and see if the ion exists and if not raise an error
• Should we leverage Plasmapy more heavily to judge the "validity" of the requested ion?

Once this is sorted, could remove some of the checking in Element that is done when creating ion instances.

CHIANTI v9 has a new file type .auto for incorporating autoionization in the level populations calculation. Need to add a reader for this file.

While some parts of the fiasco database are specific to CHIANTI, the overall package structure would be well suited to interface with other atomic databases as well, e.g.

• AtomDB
• NIST ASD
• others

This would require pulling out the database-specific code into separate modules and then developing a database-agnostic interface to the data.

To DO

-- explain hidden files. Include example

--Show the format for the rc file is strict.

Should be multiplicity instead of mult when accessing data on elvlc data.

The issue of how data should be downloaded and distributed was labelled as the biggest question on the wiki page. It seems worthwhile to raise it as an issue so as to allow some discussion.

One issue that someone else brought up is that the Chianti database does not have a license, as far as we know. This would make the legal whatever of adapting the data stored by Chianti confusing, since it's not clear if modifications or redistributions of the database are allowed. If Chianti officially adopted the MIT license like fiasco, then it would clear up any confusion.

With respect to data storage and distribution, the easiest thing would be to store all of the data files within GitHub, though they may end up being too large. The git history itself might end up getting huge that way.

Another option would be to store the HDF5 files on a site like Zenodo. I really like Zenodo because:

• Data and other research products are openly available.
• Data sets are citable (e.g., they are each given a doi)
• Versioning is supported (e.g., you can link to updated or older versions of the same data set, while each version has a different doi)
• Licensing of the data is supported
• It's at no cost to researchers
• The maximum standard data set size is 50 GB, with exceptions possibly being made for larger data sets

One option would be to store the HDF5 files on Zenodo, and then have them be downloaded during the installation process.

The excitation-autoionization collision strengths stored in CHIANTI, computed by Dere (2007), included the 1/\omega_i factor. There should be a comment in the Ion.excitation_autoionization_rate() method to this effect so that future readers do not conclude there is a bug in the calculation.

The current version of the CHIANTI database (8.0.6) uses the .scups ("SCaled UPSilon"?, where upsilon is the thermally averaged collision strength) file format while previous versions (<8.0) of the database used the .splups ("SPLine fits to UPSilon"?) file format. See Del Zanna et al. (2015) for a more complete discussion of this change.

In order to use versions <8.0, we need to provide a .splups file reader. This should be relatively low effort as there is already a .psplups file reader implemented.

Should have a way to interface with remote CHIANTI data. Two advantages:

1. Regarding issue #21, every Travis and RTD build requires the database to be downloaded and installed. This takes a long time and puts unneeded stress on these free services. This step could be cut out entirely if the data could be accessed via some HTTP endpoint.
2. Users can try out the package without having to download the database (can download locally later on if they are more concerned about performance)

This can be (relatively) easily accomplished using two packages:

• h5serv
• h5pyd

Outline

• spin up server on something like Heroku or a Digital Ocean droplet
• expose CHIANTI data on this server
• provide alternative remote version of DataIndexer object that uses h5pyd instead of h5py
• use some config option to switch between local and remote data interface

The proton collision strength files (*.psplups) store the scaled collision rate coefficients and not the scaled collisions strengths (upsilons). The descriptions and variable names should be fixed to reflect this. These files are described in Young et al., (2003)

Previously I had opened the HDF5 file directly for performance reasons. I'm not sure this is necessary.

By opening up the HDF5 file directly, I bypass the remote versus local setting which causes problems on RTD (or any place where the remote data is being used).

Could potentially replace much custom and ugly code for data loading with intake.

These are not "user-facing" and should not be included.

Need to setup some hosted documentation on Read the Docs

PlasmaPy provides conversions/lookups between names, symbols, and atomic numbers for all elements. See the atomic module in PlasmaPy. Currently fiasco uses the periodictable package to do this, but it seems more logical to use a package in the plasma physics/astrophysics ecosystem.

Currently, the level population does not include photoexcitation and stimulated emission processes. For more details, see section 2.3 of Young et al. (2003) and section 2.2 of Landi et al. (2006)

It would be great for fiasco to have continuous integration testing set up so that tests can be run every time a pull request is made or updated. Travis CI would be a good choice for continuous integration testing, and it's free for open source projects (yay MIT license!). Coveralls is a good choice to figure out which parts of the code are covered and which aren't. I haven't gone through this myself yet, as @SolarDrew was the one who set these up for PlasmaPy.

Also: this package sounds fantastic!

Can the database be reformatted to use Zarr? Zarr allows for lazy file access over HTTP. This would also allow for easy access from "the cloud" meaning we could do efficient computation from a remote dataset.

Currently, fiasco uses a simple configuration file and configparser to set some basic options for the package. Astropy has a much more robust configuration system that fiasco should take advantage of. However, it seems there are issues when it comes to using it with affiliated packages](astropy/astropy#5828).

fiasco should aim to to take advantage of this configuration system once it is suitable for packages outside of astropy. Maybe it is already?

Currently, the ionization potential is accessed via the property named ip and the equilibrium population fractions through ioneq. These are not particularly intuitive and are just inherited from the old CHIANTI syntax.

Try to come up with better, more communicative names for both.

The tutorial section currently only has examples for parsing the raw CHIANTI data. There should also be examples for how to use the Ion, Element, and IonCollection objects.

The level populations calculation is extremely computationally expensive and scales poorly with number of available transitions. This means that level populations for ions with very large number of transitions and available energy levels (e.g. Fe IX, XI) take a very long time to compute.

The level populations calculation is essentially needed for everything so poor performance here impacts many other calculations. Maybe something like numba or cython could be used to speedup this calculation or it could be parallelized using something like dask.

Currently tests are only run on Python 3.6 on Travis CI. We should be testing against 3.7 as well.

Add fancy levels in spectroscopic notation for energy levels. This can be added as a property to fiasco.Level.

For example, for an fiasco.Ion object called i,

from fraction import Fraction
label = '$^{s}{L}_{{{str(Fraction(j))}}}$'
label.format(s=i._elvlc['multiplicity'], L=i._elvlc['J'], j=i._elvlc['L_label'])

Should add this to the __repr__ for Level as well.

Not every ion has access to every dataset because not every ion in the CHIANTI database has the same pieces of information attached to it.

There should be tests to ensure that this missing data is handled appropriately.

Ideally, fiasco should be a SunPy affiliated package. The steps required are detailed in this SEP. As such, fiasco should use one of the relevant package templates:

• Astropy package template
• SunPy package template

This would also mean transferring ownership of the repo to the sunpy org.

Though the continuum data has been added to the API, no methods are yet available for computing associated quantities. These should include,

• free-free intensity and radiative loss
• free-bound intensity and radiative loss
• two-photon intensity and radiative loss

See old ChiantiPy commits, chianti-atomic/ChiantiPy#114, chianti-atomic/ChiantiPy#108, this paper, and this report for more info.

The parser and HDF5 importer currently do not support any of the continuum data files (see here for a list of these files). These files are needed for calculating the free-free, free-bound, and two-photon continua.

The reason for this is twofold:

1. They do not fall into the usual structure of element/ion/ion.filetype and so are not easily organized into the existing HDF5 structure
2. The files themselves are have no consistent format unlike the rest of the database (i.e. columns of data followed by a footer with the source of the data) and so do not play nice with the currently implemented generic parser.

Ideally, each of the files would be contained as a subgroup under a group continuum/ in the HDF5 database. Alternatively, like the abundance and ioneq files, they could be broken up by element/ion and placed as individual datasets (assuming the data can be split this way).

I've not put much effort into figuring out the actual content of these files. I'll add more to this thread as I investigate.

It is can be useful to assume constant pressure (i.e. density inversely proportional to temperature) when computing the level populations, e.g. when computing the AIA response functions.

There should be an option added to the level populations calculation to assume constant pressure which collapses the density axis to 1, but varies the density along temperature.

From @namurphy, copied from a separate thread:

One thing I was wondering about was how fiasco would handle atomic notation. I'm not so much a fan of notation like "fe_16" or "Fe XVI" since the off-by-one difference from the charge state always confuses me. I personally much prefer something like "Fe 16+" since that has the charge state built right in. At the same time, most astronomers are used to "Fe XVI". Anyway, separate question, but just thought I'd mention it.

The issue then is how exactly to denote/specify an ion?

Currently, in the IonBase class (and all derivative classes), an ion is instantiated using the notation '{atomic symbol}_{ionization stage}', e.g. 'fe_16' for Fe XVI, Fe 15+. Then, several attributes are set in the following manner,

• ionization_stage -- 16
• charge_state -- 15
• ion_name -- Fe 16

So we store both the charge state (the physical charge on the ion in units +e) and what I've called the "ionization stage" (charge state +1). The CHIANTI database still denotes all ions using the ionization stage rather than the charge state so I think it is important to keep that notation around (although I agree it is confusing).

Thinking about it a bit more, perhaps the most ideal case would be if wee could instantiate ion objects using one notation or the other, e.g.

>>> ion1 = IonBase('Fe 15+')
>>> ion2 = IonBase('Fe XVI')

This way, the use of Roman numerals versus Arabic numerals clearly denotes the difference between the two systems (as opposed to using Arabic for both the ionization stage and charge state). We could then continue to use the ionization stage variable internally (but sparingly) where needed (e.g. when reading from the database), but the user would not be exposed to this confusion.

There should be a correction for ionization and recombination processes in the level population calculation. Currently, this is not included. See section 2.3 of Landi et al. (2006) for more details as well as section 6 of Dere et al. (2009).

See #32

In order to include inline plots in the documentation, we need to download and install the database. Unfortunately, this means that both the doc tests on Travis and RTD will need to add a step where the database is downloaded and built into an HDF5 file.

Travis can handle this fine, but it means the build_docs job will take longer. This may be an issue for RTD as the build times out after 10 minutes and it is very possible that the download and HDF5 build could take longer than that.

CHIANTI v9 has now been released (see Dere et al., 2019) with additional modifications for how the level populations are calculated and a new data format.

Need to look into specifically what modifications need to be made to the level populations as well as the readers.

EDIT: This is really a "meta-issue" for general incompatibility. Try to create individual issues for each area of incompatibility.

Question: Should the Ion class subclass the Particle class from PlasmaPy?

The atomic subpackage in PlasmaPy provides an object for representing particles via the Particle class. Particle provides a convenient API to lots of metadata, e.g. mass, atomic number, symbol, etc. This would mean fiasco wouldn't have to re-implement all of this functionality.

fiasco already relies on PlasmaPy for getting the atomic number, symbol, and name.

Would there be any major conflicts with the existing Ion class and Particle? What would be the major benefits? Is the Particle API stable enough to rely that heavily on it?