Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conditional rate updates for MultiRate reactions #1151

Merged
merged 2 commits into from
Dec 4, 2021

Conversation

speth
Copy link
Member

@speth speth commented Dec 4, 2021

Changes proposed in this pull request

  • Use the RateData::update method (executed once per reaction type) to determine whether or not both updateFromStruct and evalFromStruct need to be called for all reactions of that type.
  • Remove other conditions that could cause evaluation of BulkKinetics::m_bulk_rates to be skipped incorrectly

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

The timing results from custom_reactions.py show an improvement compared to the "legacy" framework, with the new framework now outperforming the "legacy" one.

  • Current main branch:

    • New framework (YAML): 257.54 ms (T_final=2736.60)
    • One Python reaction: 273.18 ms (T_final=2736.60) ... +6.07%
    • Old framework (XML): 253.31 ms (T_final=2736.60) ... -1.64%
  • This PR:

    • New framework (YAML): 248.20 ms (T_final=2736.60)
    • One Python reaction: 268.20 ms (T_final=2736.60) ... +8.06%
    • Old framework (XML): 254.35 ms (T_final=2736.60) ... +2.48%

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

Updating the "shared data" for a rate type returns flags indicating
whether the "update" or "eval" methods for each reaction of that type
need to be called to get new values of the rate constant.
@codecov
Copy link

codecov bot commented Dec 4, 2021

Codecov Report

Merging #1151 (73db64a) into main (d5e075a) will increase coverage by 0.03%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1151      +/-   ##
==========================================
+ Coverage   73.73%   73.76%   +0.03%     
==========================================
  Files         370      370              
  Lines       48927    48983      +56     
==========================================
+ Hits        36077    36133      +56     
  Misses      12850    12850              
Impacted Files Coverage Δ
include/cantera/kinetics/MultiRateBase.h 100.00% <ø> (ø)
test/kinetics/kineticsFromScratch.cpp 100.00% <ø> (ø)
include/cantera/kinetics/MultiRate.h 74.54% <100.00%> (+2.54%) ⬆️
include/cantera/kinetics/ReactionData.h 100.00% <100.00%> (ø)
src/kinetics/GasKinetics.cpp 85.86% <100.00%> (+0.14%) ⬆️
src/kinetics/ReactionData.cpp 100.00% <100.00%> (ø)
src/thermo/Phase.cpp 85.09% <100.00%> (+0.02%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d5e075a...73db64a. Read the comment docs.

Copy link
Member

@ischoegl ischoegl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@speth … this looks like a really good solution to the update process. Thanks for looking into this, as this was one of the items that needed to be taken care of. Hadn’t thought of moving the update checks into ReactionData before seeing this, but I like this solution quite a bit, as it appears to resolve multiple issues once and for all.

Copy link
Member

@ischoegl ischoegl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that ReactionData has become a lot smarter, it may make sense to have a pure abstract parent class/struct for documentation purposes, where each of the current classes is a specialization. I don't want to include this in this PR, but I think it would make sense to implement this prior to 2.6.

@ischoegl ischoegl merged commit 6a6034f into Cantera:main Dec 4, 2021
@ischoegl ischoegl mentioned this pull request Dec 29, 2021
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants