-
Notifications
You must be signed in to change notification settings - Fork 6
Description
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.6
-
ThreeBodyReaction... see PR Remove reaction specializations cantera#1333 -
FalloffReaction... see PR Remove reaction specializations cantera#1333 -
CustomReaction... see PR Fix CustomRate segfaults and remove CustomReaction cantera#1332 -
ElectrochemicalReaction(via Refactor Electrochemical Reactions #139 and Refactor electrochemical reactions cantera#1216) - Update science documentation at https://cantera.org/science/kinetics.html to include explanations on
ThirdBodydetection
Motivation
Describe the need for the proposed change:
- What problem is it trying to solve? ... remove all specializations of
Reaction - Who is affected by the change? ... any application of
Kinetics - Why is this a good solution? ... having a single
Reactionimplementation (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 replace ThirdBodyCalc.h and work in a similar way as CoverageBase in InterfaceRate.h). Within BulkKinetics.h, there then can be two std::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 use BlowersMaselRate.
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 to CoverageData.
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 and InterfaceKinetics, which will allow for the removal of pre-processing steps that happen much earlier.