Rethink handling of 3rd body colliders

[ischoegl]

Abstract

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:

1. Attach the handling of third-body species to ArrheniusRate
2. Create a dedicated object ThreeBodyArrheniusRate
3. Keep separate FalloffReaction and ThreeBodyReaction specializations (i.e. no change)
4. Update: Create a ThirdBodyRate<ArrheniusBase> template (assuming implementation of a reduced scope Arrhenius(Base) object Cantera/cantera#1184)

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.

• Cantera/cantera#1183

• 87

• Cantera/cantera#1181
• Cantera/cantera#1089 (some newly introduced features will require reworking)
• Cantera/cantera#1084 (I do not think that there is a contradiction, as 'M' would be handled separately)
• Cantera/cantera#1143 (resolution would be made a lot easier)

[ischoegl]

Based on Cantera/cantera#1219, there is a speed penalty for alternative approaches, so ThirdBodyCalc.h will remain as is.