Newsletter #4, April 2024

This is the fourth edition of the DREAM newsletter, and it appears right on time (according to the schedule :). This time it’s packed with new features and bug fixes, and with contributions from a unusually large number of people.

Among the major news is the formation of a DREAM developer council, which consists of people who contribute significantly to the DREAM source code, and which will hopefully help us coordinate and steer future DREAM development. There are also improvements to the DREAM EQDSK reader, how the Compton runaway source is specified, as well as the adaptive ionization time stepper, and a large number of memory bugs have been fixed.

// Mathias

I. Announcements

i. DREAM developer council

Since the beginning of April, there is now a formal team of core DREAM developers who meet bi-weekly to discuss current DREAM development issues. The current team consists of Mathias Hoppe (KTH), Ida Ekmark (Chalmers), Peter Halldestam (IPP-Garching), Oskar Vallhagen (Chalmers), and Lorenzo Votta (KTH). With the development team, we hope to better coordinate and focus DREAM development, as well as increase the number of people who have a deep understanding of the code.

While the main topics of DREAM developer meetings will concern open issues and pull requests, new ideas for features, and numerical issues experienced by the developers, we also hope to occasionally invite DREAM users to present their work with the code.

II. New features

i. Improved EQDSK reader

by Mathias Hoppe

A set of utility Python scripts are available under tools/ in the main DREAM repository, and among these can be found an EQDSK driver which allows you to process EQDSK files and extract quantities used by DREAM. The original version of the script (still available as GEQDSK.py) has now been superceeded by a new, more complete version.

In addition to being able to read data from EQDSK files, the new script contains routines for exporting the data to LUKE and SOFT equilibrium formats, and for working around common numerical issues encountered with numerical equilibria. In particular, the new class supports the COCOS convention and allows the user to specify the COCOS number corresponding to the sign convention used for the EQDSK file.

ii. Generalized Compton gamma photon spectrum

by Ida Ekmark

The Compton runaway electron source used so far has assumed the photon spectrum to be as in Martin-Solis (2017). Recently, Compton photon spectrum data was generated for SPARC however, and this spectrum differs somewhat from that of ITER. Hence, a generalized fitting function has been developed and implemented in DREAM, and it is now possible to provide the fitting coefficients for that function, rather than just a photon flux. The new Compton gamma spectrum fitting function takes the form:

$$\Gamma(E_\gamma)\propto \exp\left( - \exp(-z) - z + 1 \right),$$

with

$$z = \frac{\log(E_\gamma\,[\mathrm{MeV}]) + C_1}{C_2} + C_3 \left( E_\gamma\,[\mathrm{MeV}] \right)^2.$$

iii. Diff tool for settings files

by Mathias Hoppe

When comparing two simulations which are supposed to be identical, but for which the results differ, it can be useful to compare the input files setting-by-setting. This is now possible using the settings-diff tool, located under tools/settings-diff. The tool takes the name of two DREAM settings files as input, compares every setting in the file, and generates a list of mismatched or missing settings which are presented in a convenient GUI. The user can then click through each of the mismatched settings and compare the setting values one by one.

If only an output file is available from a simulation which you would like to compare the settings for, you can still use the tool. Since DREAM output files nowadays contain a copy of the settings used in the simulations, you can specify the path to the settings structure in the given HDF5 file after a set of colons. Thus, if you want to compare the settings file settings.h5 to the settings contained in the output output.h5, you would call the settings-diff tool as follows:

/path/to/DREAM/tools/settings-diff/main.py settings.h5 output.h5:/settings

iv. Fast-electron impact ionization cross-section as OtherQuantity

by Mathias Hoppe

Fast electron impact ionization is based on a fast-electron ionization cross-section given by Garland (2020). With this update, the evaluated ionization cross-section can be stored as an other quantity, and it has the name kinioniz_vsigma.

v. Adaptive ionization time stepper for SPI

by Peter Halldestam

The adaptive ionization time stepper has been very useful to traditional uniform-deposition disruption simulations, but when used for SPI simulations it has often resulted in unacceptably small time steps, since the ionization time scale often starts out very long in the simulation, and only becomes very short when the first material reaches the plasma and starts ionizing. In this update, a user-specified parameter $\alpha$ has been introduced so that the time step can be chosen as

$$\Delta t = \min\left(\Delta t_{\rm max}, \alpha\tau_{\rm ioniz}\right),$$

where $\Delta t_{\rm max}$ is the user-specified maximum allowed time step, and $\tau_{\rm ioniz}$ is the estimated ionization time scale. To use this new functionality, the time stepper can be set up as follows:

ds = DREAMSettings()
...
ds.timestep.setIonization(dt0=1e-10, dtmax=1e-5, tmax=0.003, alpha=1e-2)

Typical values for $\alpha$ are $\alpha\leq 10^{-2}$.

III. Interface changes

i. Ion transport settings

by Lorenzo Votta and Mathias Hoppe

Previously, the ion transport could only be set when adding a new ion species to the equation system. With this update, routines for setting ion transport on already existing ions have been added. To set transport on an already existing ion species, the following code can be used:

ds.eqsys.n_i.setChargedAdvection('D', mode=, Drr=, ...)
ds.eqsys.n_i.setChargedDiffusion('D', mode=, Drr=, ...)
ds.eqsys.n_i.setNeutralAdvection('D', mode=, Drr=, ...)
ds.eqsys.n_i.setNeutralDiffusion('D', mode=, Drr=, ...)

The transport can still be specified in the call to addIon(), but for clarity it is recommended to use the new routines.

IV. Bug fixes

i. Elimination of memory leaks

by Ida Ekmark and Mathias Hoppe

With the advent of the new DREAM Python interface, memory leaks (and associated memory errors) have surfaced which are no longer acceptable. In this bug fix a large number of those issues were fixed, which should now allow for a large number of simulations to be run through the dreampyface Python interface within the same Python session.

This bug was fixed in pull request #278 and is now available on master.

ii. Incorrect interpolation in NumericBRadialGridGenerator

by Lorenzo Votta

A small error in the interpolation of $(R,Z)$ coordinates in numerical equilibria was discovered. It was fixed by manually adding a point for the magnetic axis to the input arrays in the C++ code, just before they are handed over to the interpolation routines.

This bug was fixed in pull request #273 and is now available on master.

iii. Inconsistent electron density in coronal equilibrium initialization

by Mathias Hoppe

The new coronal equilibrium initialization feature of DREAM did not satisfy quasi-neutrality in the way expected. Instead of enforcing quasi-neutrality for all ion species combined, it was enforced for each ion species separately, leading inconsistent and incorrect ion densities at the start of the simulation when initializing the ions in coronal equilibrium.

This bug was fixed in pull request #271 and is now available on master.

iv. get_nist.py unnecessarily downloading cached data

by Mathias Hoppe

Due to the NIST database not keeping data under the name D for deuterium, but rather under H for hydrogen, the get_nist.py script was never able to find data for D from the cached data but would always send a request to the NIST database when rebuilding the NIST coefficients. In this update, special cases have been added for hydrogenic species which allow their ionization threshold and binding energy data to be identified correctly.

This bug was fixed in pull request #267 and is now available on master.

v. Inconsistent sign of j_hot in isotropic mode

by Mathias Hoppe

It was discovered that the hot current density did not correctly account for the signs of the electric and magnetic fields, and so was always assumed to be positive. This would cause problems in simulations where the electric field was not positive, and effectively invalidate the isotropic model. The fix was however straightforward and not conceptually problematic, and so has been implemented.

This bug was fixed in pull request #284 and is now available on master.

IV. Recent publications

• J. Walkowiak et al, Nucl. Fusion 64 (2024)
• I. Ekmark et al, accepted for publication in J. Plasma Phys.
• O. Vallhagen et al, submitted to Nucl. Fusion