Plasma treatment enhancements

[Gaetanosaure]

Here are the changes proposed in this pull request. They all focus on the plasma modelling in cantera.

1. Solved the EEDF computation issue: the solver now converges to the right EEDF. As you may have noticed, the example on the website gets the right trend but the values are off (figures 1a and 1c). This is because the effective cross-sections and elastic cross-sections were treated in the same way whereas they should not be: effective = elastic + inelastic. This ended up in counting the inelastic cross-sections twice, thus lowering the EEDF value on the high energies with respect to the correct solution. As can be seen on figure 1b and 1d, this is now fixed.

Figure 1 – Example of EEDF calculation on the cantera website. a) current implementation - logarithmic x axis, b) Proposed pull request - logarithmic x axis, c) a) current implementation - linear x axis, d) Proposed pull request – linear x axis.

2. Corrected the physics of plasma heating. In the current version of the code, intrinsincHeating() returns the Joule effect plus the power of the discharge going into elastic collisions. This is incorrect since the work of the electromagnetic force is the Joule effect. In the proposed pull request, intrinsincHeating() only returns the Joule power.

3. Entering grid parameters instead of having to enter the grid itself in the YAML: this is much more compact and practical than having to copy-paste the grid by hand, especially when the grid reaches several hundreds of points (see figure 2 for the parameters).

4. Automatic grid adaptation to the problem faced. This feature allows for the adaptation of the maximum value of the energy grid so that in cases where the user is not sure up to which energies the EEDF should be resolved the code solves it for them (with a slight computational overhead). Both this feature and the previous one are controlled by a block electron-energy-distribution added in the YAML phase node looking roughly like this (depending on the user’s choices):

Figure 2 - New YAML phase node architecture for the EEDF calculation parameters.

The parameters to be chosen by the user are the following:
-> Initial max_energy_level: in eV, the energy level at which the energy grid will be initialized. This number can be led to change if the energy grid adaptation is activated.
-> Initial number of energy grid cells: the number of cells the user wishes to have in the energy grid. This number is not modified by grid adaptation in its current implementation but the name is chosen as is to keep compatibility with a potential later update.
-> Energy_levels_distribution: governs how the energy levels are spaced between themselves. Three options are currently available: Linear, Quadratic and Geometric. For the Geometric case, the user can also choose the geometric factor using the field geometric_grid_ratio.
-> energy_grid_adaptation block: used if the user wishes the grid to be dynamically adapted during the computation. If "enabled" is set to true, the solver checks the amount of decades lost between the head and the tail of the EEDF and compares it to "max_decay_decades" and "min_decay_decades" to decide whether to extend or shrink the current grid by a factor "update_factor" at the next iteration. The maximum amount of iterations allowed to the grid adaptation routine is chosen via "max_iterations".

5. Implemented a new format for the YAML files at the cross-roads between yours and ours, avoiding duplicates but solving the current problem of cross-section datasets inconsistency, all the while keeping readability. Hopefully you will find it satisfactory. Here is its presentation.
   The idea of this YAML format for electron collision reactions is to separate the data needed for the chemical solver from the data needed for the EEDF solver, the ultimate goal being to allow for a minimal user error while manipulating the cross-section dataset (which remains as close as possible to the original LXcat reference). However, you made a good point in the previous discussions by stressing that the reactions should not duplicate information from the cross-sections. Therefore, now all the information is stored in the cross-sections, which are themselves all stored in the electron-collisions YAML node for safety and clarity purposes. To link the reactions involving electron collisions to their data, a field “name” was added to the cross-sections, which now typically look like that:

This field is constructed from the cross-section data taken from the LXCat database as follows: databaseName_target_kind_product_threshold to create a unique identifier that is then declared in the appropriate reaction in the reaction YAML node if this reaction if wished by the user to be taken into account into the chemistry. Reactions involving electron-collisions now typically look like:

6. Added a reaction class for vibrational relaxation reactions, including detailed relaxation and relaxation modelled using the vibrational energy equation. Four possible models are currently available : one for detailed vibration named “multi-state-resolved” (taking reactions having a base rate constant in the form of the reactions given in the Zhong mechanism and a scaling using the harmonic approximation of the SSH theory), and three options implementing the relaxation rates of the mean vibrational energy for mean vibrational energy models: “constant”, “castela” and “starikovskiy”. More details about these models can be found in the documentation of the header of the new class VibrationalRelaxationRate.h. The main point is that all of these models implement the following equation for the reaction rates:

However, depending on the chosen model, all parameters are not required and some default values are applied.
7. Managed to go around the PlasmaReactor by implementing the mean vibrational energy equation model using fictitious species as energy reservoirs. This avoids having to declare a new class for each reactor in which one wishes to use a PlasmaPhase. Typically, this is done by, instead of declaring N2(v1), N2(v2), … N2(v45) , declaring one unique species N2(v), which enthalpy is shifted from that of ground N2 by a chosen energy E_res. This allows to collapse the 45 species equations for the vibrational levels of N2 into one species equation for N2(v). The reactions supposed to produced a vibrational level v_i are then declared as such in the YAML file:
N2 + Electron => Electron + alpha*N2(v) + (1-alpha)*N2,
Where alpha is defined as E_shift_v_i / E_res.
To avoid interfering with chemistry we recommend taking a high value with respect to dissociation energy for instance for E_res (in order to get small N2(v) concentration). To avoid mistakes and to enhance readability it is also recommended to take the same E_res for each vibrational species declared.

The changes proposed here are validated on figure 3 against the test case computed in the two following papers:

Harry Gillingham, Thomas Lesaffre, Nicolas Barléon,
A semi-analytical model for Plasma-Assisted Combustion: Application to NH3-H2-air mixtures,
Combustion and Flame,
Volume 283,
2026,
114528,
ISSN 0010-2180,
https://doi.org/10.1016/j.combustflame.2025.114528.

and

Xingqian Mao, Hongtao Zhong, Ning Liu, Ziyu Wang, Yiguang Ju,
Ignition enhancement and NOx formation of NH3/air mixtures by non-equilibrium plasma discharge,
Combustion and Flame,
Volume 259,
2024,
113140,
ISSN 0010-2180,
https://doi.org/10.1016/j.combustflame.2023.113140.

_Figure 3 - - Validation of the new cantera plasma implementations against the Mao test case._

AI Statement (required)

• Limited use of generative AI.
  Standard or boilerplate code snippets were generated with AI and manually reviewed;
  all design, logic, and implementation decisions were made by the contributor.
  Examples: IDE code-completions or brief LLM queries for common patterns.

Closes #

[speth]

Hi @Gaetanosaure, thank you for sharing this PR. It looks like there are several interesting things here. Are there some changed input files that need to be committed and included with this PR? You mention a number of changes to the input format, but I don't see any changes to any input files demonstrating them. I assume this is also the reason for some of the CI failures.