Eliminate Remaining Reaction Specializations when using MultiRate Evaluators #142
Closed
4 of 5 tasks
Labels
feature-request
New feature request
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: