-
Notifications
You must be signed in to change notification settings - Fork 6
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
Eliminate Remaining Reaction Specializations when using MultiRate Evaluators #142
Closed
4 of 5 tasks
Labels
feature-request
New feature request
Comments
This was referenced Mar 13, 2022
This was referenced Jul 5, 2022
77 tasks
speth
added a commit
to speth/cantera-website
that referenced
this issue
Jul 12, 2023
speth
added a commit
to speth/cantera-website
that referenced
this issue
Jul 12, 2023
speth
added a commit
to Cantera/cantera-website
that referenced
this issue
Aug 5, 2023
github-project-automation
bot
moved this from In Progress
to Done
in Cantera 3.0 Release Planning
Aug 22, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Abstract
After Cantera/cantera#1183 and Cantera/cantera#1181, most
Reaction
specializations for the 'new'MultiRate
-based framework no longer require specializations. It would be good if the following specializations could be eliminated prior to the release of Cantera 2.6ThreeBodyReaction
... see PR Remove reaction specializations cantera#1333FalloffReaction
... see PR Remove reaction specializations cantera#1333CustomReaction
... see PR Fix CustomRate segfaults and remove CustomReaction cantera#1332ElectrochemicalReaction
(via Refactor Electrochemical Reactions #139 and Refactor electrochemical reactions cantera#1216)ThirdBody
detectionMotivation
Describe the need for the proposed change:
Reaction
Kinetics
Reaction
implementation (which takes care of the law of mass action) will move all specialized behavior toReactionRate
, which will result in simpler API's.Possible Solutions
Bulk Phase. The simplest approach would be to introduce
BulkRate.h
where handling of third-body efficiencies is implemented on a per-reaction basis (this would replaceThirdBodyCalc.h
and work in a similar way asCoverageBase
inInterfaceRate.h
). WithinBulkKinetics.h
, there then can be twostd::vector<unique_ptr<MultiRateBase>>
objects: one for regular rates (i.e.m_bulk_rates
), and the other one for third-body rates (e.g.m_thirdbody_rates
)>. This has the additional advantage that it will be simple to define third-body reactions that useBlowersMaselRate
.Electrochemical Reactions. Again, the simplest solution would be to add two
std::vector<unique_ptr<MultiRateBase>>
objects: one taking care of regular interface reactions, and the other one being specific to electrochemical reactions. The only thing that needs to be done is to add some electrochemistry-specific information toCoverageData
.In both cases, the identification of third-body and electrochemical reactions can be deferred until very late in the process, i.e. a classification can be avoided until reactions are added by
BulkKinetics
andInterfaceKinetics
, which will allow for the removal of pre-processing steps that happen much earlier.The text was updated successfully, but these errors were encountered: