1. History of the AtomDB Project
The AtomDB project was originally designed to model X-ray emission from collisionally ionized, optically thin plasma in thermal equilibrium. It built on a history of development, starting with the Raymond–Smith code [
1] in 1977 which created spectra for the most abundant 12 elements in a hot plasma using tabulated Gaunt factors and effective collision strengths. In 1985, this was updated by Brickhouse, Raymond, and Smith [
2] to improve both the code and atomic data, particularly for the iron L- and K-shell ions. Effective collision strengths were updated and, significantly, the atomic data was separated from the code into independent data files.
In 2001, the first version of AtomDB was released [
3]. This included the first release of the publicly accessible atomic database (APED: Astrophysical Plasma Emission Database), complete with defined filetypes as standardized FITS files [
4]. In addition, the thermal plasma model, the Astrophysical Plasma Emission Code (APEC), was written and used to convert this database into line and continuum emissivities, which were and are still used extensively in spectral analysis tools such as XSPEC [
5] and Sherpa [
6]. This was accompanied by another large scale update to the atomic data in APED, in particular for modeling He-like and H-like ions.
In 2012, AtomDB version 2 was released [
7]. This again included a large update to atomic data in APED: Ionization and recombination rates were updated, along with new excitation data for He-like and H-like ions. In addition, APED was expanded to include all the elements up to Nickel (previously it had covered only the 14 most abundant elements).
Four years later, AtomDB version 3 was released. This involved a major expansion of the code, the database and tools used to interpret the spectra to allow for the modeling of non-equilibrium ionization plasma, as well as updates to existing atomic data. In particular, there was a need to handle much larger data files (inner shell processes opened up many new levels), calculations for one ion at a time, and new input and output formats suitable for more flexible spectral analysis.
This large scale restructuring of the code exposed inflexibility in the APEC code, which had been designed to run from start to finish and produce one complete output file for the APEC model. To allow for future flexibility, the entire project was shifted to python with the release of the open source
PyAtomDB (
https://github.com/AtomDB/pyatomdb), which now underpins all aspects of the AtomDB project.
During and subsequent to this, we discovered that new data formats allowed for a significant improvement in AtomDB’s capabilities, enabling a wide range of additional models to be produced. In this paper, we will outline the PyAtomDB project, the new data formats created for non-equilibrium modeling, the new models which this has enabled for charge exchange (CX), non-Maxwellian electrons (Kappa), and the ability to perform uncertainty studies.
1.1. The Astrophysical Plasma Emission Database (APED)
The AtomDB database consists of a selection of data for every ion from H to Ni, all stored as binary FITS (
http://fits.gsfc.nasa.gov/fits_standard.html) table files. The data are stored in several different files for each ion, separated by process. Throughout the database, all ions are indexed by their ion charge plus one, so for example He_1 is neutral Helium, and files related to it are stored in the directory
$ATOMDB/APED/he/he_1/. There are up to eight different file types for each ion, as listed in
Table 1. In addition, APED contains several multi-element files, which hold data covering many ions together, as described in
Table 2.
Data in the APED is stored as close to the original data format as possible. As a result, there is no single standard for values that are frequently represented as functions, such as collision strengths. Instead there are 10 or more different formats ranging from temperature/value pairs to fit coefficients, each of which can then be interpreted by the APEC code to produce the actual rate coefficient or other value required. This can be confusing for an end user, so part of the motivation for PyAtomDB was to provide a unified interface allowing users to request a piece of atomic data and get the actual rate or coefficient back, instead of the raw fit parameters, etc., which require further interpretation. This accessibility improvement makes using data in other models significantly easier.
1.2. The Astrophysical Plasma Emission Code (APEC)
APEC reads APED and processes the data using a collisional-radiative model to produce line and continuum emissivities on a set temperature and density grid. The plasma is assumed to be optically thin. For each ion at each grid node the excitation rates are calculated and combined with the spontaneous emission coefficients to form a collisional radiative matrix connecting the populations of all levels. Solving this gives level populations through simple multiplication and line emissivities per ion. Ionization and recombination into excited levels is also included in this matrix.
These line emissivities are then multiplied by the elemental abundance (by default [
8]), and the ion population in equilibrium to produce the emissivity
for each line:
where
is the spontaneous emission coefficient from level
i to
j,
is the number density of ions in excited state
i,
is the number density of the ion,
is the number density of the element, and
is the number density of hydrogen. Therefore these terms from left to right are the spontaneous emission coefficient, the level population, the ion fraction, the elemental abundance relative to hydrogen, and the hydrogen density.
APEC then produces two output files for the plasma, storing two kinds of emissivity data. The
line file contains the
, wavelength, ion and transition identification for each line above a set
(by default,
ph cm
3 s
−1). The
coco files contain the continuum emissivities from bremsstrahlung, radiative recombination and two photon decay, in ph cm
3 keV
−1 s
−1, compressed onto an emissivity vs energy grid by an algorithm [
9] which ensures that when the table is linearly interpolated the result is within 1% of the original emissivity value at every point. This is stored on an element by element basis, assuming equilibrium ionization fractions. The
coco file also contains the sum of the emission from weak lines not contained in the
line file, known as the pseudocontinuum, which is compressed in the same way as the continuum. Within these two files, both of which are standard FITS files, the first Header/Data Unit (HDU) is the list of temperatures, then each subsequent HDU contains the line or continuum emission for one of these temperatures. This data can then be rapidly read by fitting codes such as XSPEC and used to analyze data, interpolating between neighboring temperatures in
space.
With AtomDB 3, the introduction of the non-equilibrium ionization (NEI) model means that the ionization fraction, , could not be assumed to be fixed. There are therefore new nei versions of the same data files that do not have this factor included in their emissivity, and for each line and continuum component specify the driving ion which created the feature, as opposed to just the element or ion of the line. For example, the forbidden line of He-like O can originate from the excitation of O6+, ionization of O5+, or recombination of O7+. Creating a model spectrum then involves calculating the ionization fraction for the plasma in question and then multiplying the tabulated emissivities by this to the result to obtain the final emissivity for the model.
1.3. PyAtomDB
The introduction of AtomDB 3 created a vastly larger database to handle all of the underlying atomic processes involved in non-equilibrium processes. In particular, inner-shell excitation and ionization, along with excitation-autoionization, were included in the database for the first time and it was necessary to include ions that are not significant emitters in the X-ray region in equilibrium plasmas, such as M-shell ions.
Initially, APEC was modified to handle these data sets, although it became clear that this was not an efficient method for handling this. The original code started by loading all of the atomic data in the database, then iterating over each temperature, density, element, and ion to produce the spectra. Due to the code’s structure, changing the memory storage alone (required due to the entire database no longer fitting in a reasonable machine’s memory) required a complete re-write of the code. While doing this, it was also converted to Python due to the ease of development, support across different systems, widespread existing use in astronomy, and existing relevant packages such as Astropy [
10,
11] which
PyAtomDB now uses. This conversion enables several long term goals of the project: Users can now run the code themselves, direct access to the APED is possible for those wishing to integrate atomic data lookups into their code, and spectral models based on APED can be developed by users and integrated easily into analysis tools. The resulting six different modules of the PyAtomDB package are listed in
Table 3.
A full manual of the capabilities of PyAtomDB is beyond the scope of this paper. We will instead highlight some of the capabilities of the spectrum module, creating spectra of interest to end users, and extensions to it for modeling different, non-standard plasma types and investigating the effects of uncertainties on atomic data.
2. Spectral Modeling with PyAtomDB
The
spectrum module in PyAtomDB contains routines for creating collisional ionization equilibrium (CIE) spectra of thermal plasmas, complete with applying instrument responses. These tools are also provided with wrappers, allowing them to be used in PyXspec (
https://heasarc.gsfc.nasa.gov/xanadu/xspec/python/html/).
2.1. Non-Equilibrium Ionization Modeling
In addition to simple CIE plasmas, there are extensive models for NEI plasmas within PyAtomDB. These models represent a plasma where the electron temperature has rapidly changed, however the charge state distribution of the ions has not yet had time to reach a new equilibrium at this temperature. As the timescale for ionization and recombination is significantly longer than that for individual level populations to change, there is significant emission from ions at temperatures where they would not normally be observed in CIE. Such plasmas can be found in any place with shock heating—for example young Supernova Remnants (SNR) where the reverse shock rapidly heats the electrons leaving the plasma in an ionizing state until the plasma reaches equilibrium again e.g., [
12]. Similarly, a recombining plasma, where the electrons have undergone a rapid cooling, can be found in many Mixed Morphology SNR, where rapid expansion leads to rapid cooling of the electrons and a subsequent recombination dominated plasma [
13].
Figure 1 shows an equilibrium, ionizing from
keV and recombining from
keV spectrum for a
keV plasma at an ionization timescale of
cm
−3s. The ionizing case is dominated by He-like lines of Si and Ne, while the recombining case shows significant emission from He- and H-like Fe, as well as the H-like Si and Mg ions.
This model is identical to the existing
rnei model in XSPEC, but has additional flexibility such as allowing the user to identify strong lines in a selected wavelength region of a non-equilibrium plasma. There is a similar model for a plane-parallel shock (
pshock) [
12].
2.2. Non-Maxwellian Modeling
Non-Maxwell–Boltzmann electron energy distributions can occur in a range of astrophysical plasmas such as the Earth’s magnetosphere [
14], supernova shock waves (e.g., [
15]), or solar flares (e.g., [
16]). In these cases, the electron energy distribution is not well represented by a Maxwellian distribution due to an excess of high energy electrons. These can be modeled by a
distribution:
where:
When approaches its lower limit of 3/2, the distribution is highly non-Maxwellian, when it is once again Maxwellian.
Most electron energy dependent atomic data is, however, collated assuming the electron energies follow a Maxwellian distribution, as it saves substantial disk space, speeds computation of emissivities, and is relevant to the majority of applications. In theory the parameters such as electron collision strengths could be recalculated from first principles for non-Maxwellian plasmas, however the underlying cross section data either no longer exists for the vast majority of ions or, if they are, are too unwieldy for practical use. As a result, representing the
distribution as a sum of Maxwellian plasmas presents an attractive compromise. We have implemented [
17] the decomposition method of [
18] to create spectra for non-Maxwellian plasma, wherein several different Maxwellian temperatures are added to closely approximate a true
energy distribution.
Initially this was to be performed as a complete rewrite of the underlying model, however with the flexibility of PyAtomDB and the new data formats, we are able to achieve this using a simple 2-step process: The effective ionization and recombination rates are calculated by appropriately summing the Maxwellian rates as shown in
Figure 2, the charge state distribution is calculated, and then the non-equilibrium emissivities can be combined with these to provide a non-Maxwellian spectrum.
2.3. Charge Exchange
Charge exchange occurs when a donor ion or atom with one or more electron still attached interacts with a recombining ion, which is missing at least one electron, resulting in the transfer of the electron from the donor to the receiver:
where
R is the recombining ion, and
D is the donor. In most situations where charge exchange is postulated (e.g., the solar wind), the donor is neutral hydrogen as the only element with a significant enough abundance for the interaction to be observable. Typically, the exchanged electron is captured into an excited state of the ion, and these are often significantly higher
n and
l shells than those populated by electron impact excitation. As the ion relaxes to its ground state, the line emission is therefore significantly different from that observed in a typical thermal plasma. In some cases this can allow for the direct identification of CX, but in many more cases the foreground CX emissions adds an additional nuisance component to the spectrum of interest.
We released version 1 of the AtomDB Charge Exchange (ACX) model in 2014. This used a combination of analytical
nl shell capture distribution formulae with a cascade to ground calculated through the APED database to create spectra useful for identifying CX emission [
19], and successfully used it to model the spectrum of the hot and cool solar wind components.
However, the model had several shortcomings. On the physics side, the CX process was modeled without any velocity dependence, with the user selecting from one of four analytical cross section models to see which worked best. On the implementation side, the model relied on a computationally expensive process combining the AtomDB database to produce the spectra and line lists of interest. This meant that as the APED database was updated in the future, the changes in line wavelength and A-values were not reflected in the ACX model.
To expand the model, for ACX version 2 theoretical charge exchange cross sections (as opposed to the analytical
distributions), including velocity dependent effects, were obtained from the Kronos database [
20,
21,
22]. PyAtomDB was then used to create spectra for capture into each
shell, and subsequent cascade to the ground state. By treating each of these as independent spectra, as if they were separate ions in the NEI model, spectra can be rapidly created in two steps: First, the cross section for capture into each
shell is calculated, then the spectrum for each
shell is multiplied by this cross section and then summed:
where
is the total
CX emissivity,
is the shell captured into,
E and
v are the energy and velocity of the center of mass of the donor-recombining ion, and
is the emissivity for capture into that one specific
.
2.4. Cross Section Data Selection
The Kronos database contains only nlS selective cross sections for collisions with a hydrogen donor and a H-like recombining ion, and also for the bare recombining ion of C, N, O, and Ne. For all other bare ions, and for He as the donor, data is only resolved to the n shell.
In the case of nlS resolved data, the total capture into all the states which match the nlS is split evenly. For n resolved data the l shell distribution is handled by one of the analytical distribution functions described for ACX version 1 (the user may choose which one). For all other ions, where there is no data in the Kronos database, the model falls back to the ACX 1 models, with the total cross section fixed at cm2.
Within the Kronos database, there are often different data sets present for the same ion. As the authors of the database themselves advised, we choose the data which exists from the best available technique if no specific set is recommended. The techniques are ranked from quantum molecular orbital close coupling (QMOCC) [
23], atomic orbital close coupling (AOCC) [
24], classical trajectory monte carlo (CTMC) [
25,
26], to multi-channel Landau Zener (MCLZ) [
27].
2.5. Spectral Generation
For each nl or nlS to which capture is possible given the cross section in the Kronos database, we calculate the spectrum by creating a radiative matrix assuming no further collisional excitation as the electron cascades to the ground state. The A-values are taken from the AtomDB database for all ions where they exist.
For some heavier ions, the
n shell for capture ends up being very high, e.g., 16 for the donor Fe
25+. This is beyond the AtomDB holdings, which stop at
for He- and H-like ions and at
7 for all other ions. For these cases we have topped up the existing AtomDB A-values and wavelengths using calculations from A
utostructure [
28]. Where possible, the wavelengths for these calculations have been shifted to match the NIST ASD [
29] values. The new energy levels were matched to the existing AtomDB levels using energy-order, symmetry, and degeneracy matching. For the Li-, He-, and H- like ions these matches were relatively trivial, though in the middle of the Fe L shell ions this matching becomes more problematic. Fortunately, the inaccuracies introduced by poor wavelengths at high energies in these complex ions can be largely discounted due to the fact that the sheer number of lines prevents any one line from producing a strong spectral signature. By contrast, a simple ion such as O
7+ has a straightforward series of lines with well established wavelengths, and therefore discrepancies would be more pronounced.
Constructing the model in PyAtomDB has two distinct advantages: It allows the model to be rapidly developed (as it reuses most of the tools for NEI plasma) and it enables users to deploy it using the same commands.
4. Summary
The new PyAtomDB package had been released as open source code. It is now possible for the astronomy community to obtain all of the data, thermal plasma codes, and spectral models based on the project, and to develop extensions based on it.
We have developed modules for charge exchange and non-Maxwellian electrons, which are compatible with PyAtomDB and analysis tools such as PyXspec. The code can easily be extended to include new models the community may contribute.
In addition, we have used the newly available codes to develop a tool for estimating the sensitivity of spectral diagnostics to uncertainties in the underlying atomic data, which is immediately applicable to a range of plasmas for upcoming high resolution missions such as XRISM.