Incorporating the LMR-R mixture rule into Cantera for the first time

[pjsingal]

Changes proposed in this pull request

• LmrRate.cpp and LmrRate.h allow for vastly improved consideration of the mixture-dependent aspect of the rate constants for complex-forming ("pressure-dependent") reactions, using the new LMR-R mixture theory developed by the Burke Lab at Columbia University

• This code builds, runs, and produces results that have been validated and peer-reviewed

• LMR-R can handle three different representations of the pressure-dependent aspect of complex-forming reactions: Troe, PLOG, and Chebyshev

• LMR-R calculates the mixture-dependent aspect using temperature-dependent third-body efficiencies that have been supplied by the user for at least one collider - these parameters can be provided in either relative or absolute terms, as long as the user's choice is consistent for all colliders in a given reaction

• Description of the theory and instructions for implementation have been added to rate-constants.md and reactions.rst, respectively

• Four new Python examples have been added

Checklist

[x] The pull request includes a clear description of this code change
[x] Commit messages have short titles and reference relevant issues
[x] Build passes (scons build & scons test) and unit tests address code coverage
[x] Style & formatting of contributed code follows contributing guidelines
[x] The pull request is ready for review

[codecov]

Codecov Report

Attention: Patch coverage is 0.78740% with 252 lines in your changes missing coverage. Please review.

Project coverage is 72.87%. Comparing base (ec0cfdb) to head (0eb6e58).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
src/kinetics/LinearBurkeRate.cpp	0.00%	224 Missing ⚠️
include/cantera/kinetics/LinearBurkeRate.h	0.00%	15 Missing ⚠️
interfaces/cython/cantera/reaction.pyx	14.28%	12 Missing ⚠️
src/kinetics/ReactionRateFactory.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1710      +/-   ##
==========================================
- Coverage   73.23%   72.87%   -0.37%     
==========================================
  Files         381      383       +2     
  Lines       54375    54616     +241     
  Branches     9251     9282      +31     
==========================================
- Hits        39823    39802      -21     
- Misses      11580    11832     +252     
- Partials     2972     2982      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ischoegl]

Thanks for this contribution, @pjsingal! I have a couple of basic recommendations that mostly pertain to formatting. The example data should likely move to the new example_data repository, but it is not urgent at the moment. You may also want to think about adding unit tests.

[speth]

Thanks for the continued work on this, @pjsingal. I would suggest that the first priority at this point is to add some unit tests. I would recommend getting those into place before making any of the other changes that I've suggested below, so you can be sure that making those changes doesn't introduce any regressions.

[speth]

Since this seems to be the most common case (based on the mechanism used in the examples), for the sake of efficiency I think you want to avoid recalculating the value of rateObj_M for each collider when (I think) it will just have the same value for all of them and all you really need is to compute it once and scale it by the sum of the efficiency-weighted mole fractions.

[pjsingal]

This case actually only applies to colliders which have been explicitly specified with an eig0 or eps value but lack a k(TP) parameterization. For example, in the reaction H + O2 (+M) <=> HO2 (+M) this applies to only He, N2, H2, CO2, NH3, and H2O (thereby leaving 36 other species to be calculated later on in one step using the mole fraction sum). If Troe/PLOG/Chebyshev were provided for He, e.g., then it would be treated using the other branches of this conditional structure. Modifying this aspect of the code would make evalFromStruct() more complicated later on. I would prefer to leave it as-is, but am happy to modify it if you think the computational cost is too high.

[speth]

You should be able to get the constructor from input_data working by following the example of the other rate types. This is just a Python data structure containing the same information as the YAML input.

I think you can just remove the rates kwarg -- I'm guessing that's just leftover from copying from the PlogRate implementation.