Improve performance of Arrhenius rate evaluations

[speth]

Changes proposed in this pull request

• Use Eigen to vectorize rate evaluations
• Only do calculations for rates that are actually temperature-dependent

If applicable, provide an example illustrating new features this pull request is introducing

Testing this on a couple of different machines shows a 7-9% speed increase for an adiabatic flame speed calculation using GRI 3.0 (using a modified version of adiabatic_flame.py, and about a 4% speed increase for the custom-reactions.py benchmark:

Before:

Average time of 100 simulation runs for 'gri30.yaml' (CH4)
- New framework (YAML): 59.38 ms (T_final=2736.60)
- One Python reaction: 60.01 ms (T_final=2736.60) ... +1.07%
- Old framework (XML): 59.07 ms (T_final=2736.60) ... -0.52%

After

Average time of 100 simulation runs for 'gri30.yaml' (CH4)
- New framework (YAML): 57.02 ms (T_final=2736.60)
- One Python reaction: 57.67 ms (T_final=2736.60) ... +1.14%
- Old framework (XML): 59.04 ms (T_final=2736.60) ... +3.53%

The bulk of the benefit seems to come from skipping rate updates for rates that are constant (for reference, there are 100 such rates in the GRI 3.0 mechanism). I'm not quite sure why vectorizing the the rate evaluation for the remaining reactions has so little impact.

Checklist

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

[codecov]

Codecov Report

❌ Patch coverage is 85.00000% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 65.46%. Comparing base (719275e) to head (46b3f27).
⚠️ Report is 3425 commits behind head on main.

Files with missing lines	Patch %	Lines
src/kinetics/Arrhenius.cpp	83.63%	5 Missing and 4 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1217      +/-   ##
==========================================
+ Coverage   65.43%   65.46%   +0.02%     
==========================================
  Files         320      320              
  Lines       46249    46308      +59     
  Branches    19657    19687      +30     
==========================================
+ Hits        30265    30315      +50     
- Misses      13454    13459       +5     
- Partials     2530     2534       +4     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ischoegl]

This is an interesting concept. Presumably, vectorization could be done for each/most of the other ReactionRate specialization also? Fwiw, my recent tests on #1219 indicate that there should be gains whenever updateFromStruct can be avoided for individual rate evaluators. Given that we have a lot of features already accumulated in 2.6.0a4, I'm wondering whether to include this now or for 3.0.

As an aside, I'm surprised that your speed tests put the CTI/XML ahead of YAML. I currently have YAML with an edge of around 4% on main. It's likely compiler/hardware dependent, though.

[ischoegl]

@speth … do you think that the speedup arises from vectorization via Eigen or from omitting calculations? If I understand correctly, only the former creates complications for the test you ran in the context of #1211 (comment)?

[speth]

@speth … do you think that the speedup arises from vectorization via Eigen or from omitting calculations? If I understand correctly, only the former creates complications for the test you ran in the context of #1211 (comment)?

As I said in the initial PR description, the bulk of the benefit seems to come from skipping rate updates for rates that are constant.

[speth]

I'm closing this as it's now horribly out of date and I have some different (hopefully better) ideas on how to accelerate these calculations.