You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, third body colliders are handled by ThirdBodyCalc.h, which is managed by Reaction objects. Specifically, there are two dedicated reaction specializations, - ThreeBodyReaction and FalloffReaction - that implement 3rd body colliders, whereas this feature is unused by others.
Cantera/cantera#1183 removes several Reaction specializations as the new framework introduced in #87 has already moved most reaction-specific functionality to ReactionRate (at least for GasKinetics). Ongoing work on Cantera/cantera#1181 also indicates that no specializations are needed for InterfaceKinetics. It is anticipated that the handling of 3rd-body colliders is the only remaining outlier in the new implementation framework.
Motivation
Describe the need for the proposed change:
What problem is it trying to solve? ... completely eliminate Reaction specializations (i.e. remove ReactionFactory together with CTI/XML)
Who is affected by the change? ... all Cantera users
Why is this a good solution? ... reduction of complexity
Possible Solutions
There are four solutions:
Attach the handling of third-body species to ArrheniusRate
Create a dedicated object ThreeBodyArrheniusRate
Keep separate FalloffReaction and ThreeBodyReaction specializations (i.e. no change)
For (1), (2) and (4), the rate object would calculate M and make it available to GasKinetics (instead of having this handled in a separate step). Either would (at least partially) replace ThirdBodyCalc.h.
Other thoughts
with (1), attaching more functions will make ArrheniusRate a 'catch-all'. As it is the most frequently used rate parameterization, this may affect performance
with (2), no further specializations are needed for FalloffRate, as they inherently involve 3rd-body colliders
it is possible to extend third-body reactions to other reaction rate types, e.g. BlowersMasel
A similar question (attach optional functions or create separate specializations?) arises in the context of InterfaceKinetics. Specifically, coverages and sticking behavior are implemented for both Arrhenius and BlowersMasel variants.
Overall, I believe (1) will allow for a slimmer API but may penalize performance, whereas (2) will create more specializations. At the moment, I have a strong preference for option (4), as it may be the best way forward for Cantera/cantera#1181 as well.
References
Links to related Pull Requests, GitHub Issues, Users' Group topics, or other relevant material.
Abstract
At the moment, third body colliders are handled by
ThirdBodyCalc.h
, which is managed byReaction
objects. Specifically, there are two dedicated reaction specializations, -ThreeBodyReaction
andFalloffReaction
- that implement 3rd body colliders, whereas this feature is unused by others.Cantera/cantera#1183 removes several
Reaction
specializations as the new framework introduced in #87 has already moved most reaction-specific functionality toReactionRate
(at least forGasKinetics
). Ongoing work on Cantera/cantera#1181 also indicates that no specializations are needed forInterfaceKinetics
. It is anticipated that the handling of 3rd-body colliders is the only remaining outlier in the new implementation framework.Motivation
Describe the need for the proposed change:
Reaction
specializations (i.e. removeReactionFactory
together with CTI/XML)Possible Solutions
There are four solutions:
ArrheniusRate
ThreeBodyArrheniusRate
FalloffReaction
andThreeBodyReaction
specializations (i.e. no change)ThirdBodyRate<ArrheniusBase>
template (assuming implementation of a reduced scopeArrhenius(Base)
object Preamble to InterfaceKinetics refactoring cantera#1184)For (1), (2) and (4), the rate object would calculate
M
and make it available toGasKinetics
(instead of having this handled in a separate step). Either would (at least partially) replaceThirdBodyCalc.h
.Other thoughts
ArrheniusRate
a 'catch-all'. As it is the most frequently used rate parameterization, this may affect performanceFalloffRate
, as they inherently involve 3rd-body collidersBlowersMasel
InterfaceKinetics
. Specifically, coverages and sticking behavior are implemented for bothArrhenius
andBlowersMasel
variants.Overall, I believe (1) will allow for a slimmer API but may penalize performance, whereas (2) will create more specializations. At the moment, I have a strong preference for option (4), as it may be the best way forward for Cantera/cantera#1181 as well.
References
Links to related Pull Requests, GitHub Issues, Users' Group topics, or other relevant material.
The text was updated successfully, but these errors were encountered: