Rethink handling of duplicate reactions

[speth]

Abstract

The current mechanism for handling "duplicate" reactions is mostly an attempt to replicate the corresponding syntax from the Chemkin format. However, I think there are some unwritten rules to this that we shouldn't necessarily try to replicate, and we have potentially better ways of handling reactions where the rate is a combination of different rates.

Motivation

Requiring reactions to be labeled as duplicates is an attempt to catch certain kinds of errors when assembling reaction mechanisms from multiple sources. However, it has a number of limitations.

1. Reactions of different "types" are not considered duplicates, even if they have the same reactants and products. But in most cases, the "type" of a reaction is just a parameterization, and has no deep physical meaning, and it's certainly possible that two mechanisms could use different parameterizations (say, Plog or Chebyshev) for the same reaction, where we would want to identify these as duplicates.
2. There is no "reverse" checking, i.e. that a reaction marked as duplicate actually has a duplicate in the mechanism. Nor is there an indicator of how many duplicates a reaction has, so while combining mechanisms that already include duplicate reactions, those groups of duplicates won't be identified as errors.

Possible Solutions

I think there are a couple of things that can be done, with different levels of difficulty.

1. Treat reactions as potential duplicates regardless of the reaction "type". I guess for cases like third-body reactions, this requires deciding whether a reaction like A+B=C+D and A+B+M=C+D+M are considered as duplicates. If we change our definition of duplicate, I think we would want to update ck2yaml to provide a way of automatically setting relevant reactions as duplicates if the would not have satisfied Chemkin's duplicate reaction definition, and provide a way of automatically updating mechanisms to correspond to these rules.

2. Provide a way of actually writing "duplicate" reactions as a single reaction with multiple rates. I think this should be somewhat easier with the improved infrastructure for handling reaction rates that's been introduced by Refactor Reaction Rate Evaluators #87. As a simple example,

- equation: OH + H2O2 <=> HO2 + H2O  # Reaction 88
  duplicate: true
  rate-constant: {A: 2.0e+12, b: 0.0, Ea: 427.0}
- equation: OH + H2O2 <=> HO2 + H2O  # Reaction 89
  duplicate: true
  rate-constant: {A: 1.7e+18, b: 0.0, Ea: 2.941e+04}

could instead be written as:

- equation: OH + H2O2 <=> HO2 + H2O
  rate-constants:
  - {A: 2.0e+12, b: 0.0, Ea: 427.0}
  - {A: 1.7e+18, b: 0.0, Ea: 2.941e+04}

For example, the following set of reactions from GRI 3.0:

- equation: H + O2 + M <=> HO2 + M  # Reaction 33
  type: three-body
  rate-constant: {A: 2.8e+18, b: -0.86, Ea: 0.0}
  efficiencies: {O2: 0.0, H2O: 0.0, CO: 0.75, CO2: 1.5, C2H6: 1.5, N2: 0.0,
    AR: 0.0}
- equation: H + 2 O2 <=> HO2 + O2  # Reaction 34
  rate-constant: {A: 2.08e+19, b: -1.24, Ea: 0.0}
- equation: H + O2 + H2O <=> HO2 + H2O  # Reaction 35
  rate-constant: {A: 1.126e+19, b: -0.76, Ea: 0.0}
- equation: H + O2 + N2 <=> HO2 + N2  # Reaction 36
  rate-constant: {A: 2.6e+19, b: -1.24, Ea: 0.0}
- equation: H + O2 + AR <=> HO2 + AR  # Reaction 37
  rate-constant: {A: 7.0e+17, b: -0.8, Ea: 0.0}

might instead be written as (very roughly):

- equation: H + O2 + M <=> HO2 + M
  rate-constants:
  - rate-constant: {A: 2.8e+18, b: -0.86, Ea: 0.0}
    third-body: M
    efficiencies: {CO: 0.75, CO2: 1.5, C2H6: 1.5}
  - rate-constant: {A: 2.08e+19, b: -1.24, Ea: 0.0}
    third-body: O2
  - rate-constant: {A: 1.126e+19, b: -0.76, Ea: 0.0}
    third-body: H2O
  - rate-constant: {A: 2.6e+19, b: -1.24, Ea: 0.0}
    third-body: N2
  - rate-constant: {A: 7.0e+17, b: -0.8, Ea: 0.0}
    third-body: AR

While this is obviously quite a bit more complicated to implement, I think it would have benefits for end users, where groups of reactions like these are really perceived as a single reaction and the need to split them into multiple reactions is an artificial result of how some modeling tools require the rates to be parameterized. Reactions with explicit reverse rates also fall into this category, where Cantera splits them up even though they really should be considered as a single reaction. Of course, the same need for automatically converting reactions to this style would exist as with (1).

[ischoegl]

Thanks for opening this issue, I think this is interesting. FWIW, I am also referencing Cantera/cantera#704 and Cantera/cantera#1019.

[ischoegl]

Linking user group discussion and Cantera/cantera#1193 - as an example, prior to Cantera 2.6, the following duplicate reactions worked (as the second version was not detected as a third-body reaction). Starting in Cantera 2.6, the reactions require a duplicate declaration to prevent the following error:

*******************************************************************************
InputFileError thrown by Kinetics::checkDuplicates:
Undeclared duplicate reactions detected:
Reaction 6: H + O2 + M <=> HO2 + M
Reaction 5: H + O2 + O2 <=> HO2 + O2
*******************************************************************************

[corykinney]

@ischoegl Would it be possible to have ck2yaml automatically flag these as duplicates in the converted file (even though they are not declared that way in the CHEMKIN file) since Cantera is rightfully treating them as duplicates, or would automatically doing so would be undesirable? Additionally it could set a collision efficiency of zero on the generic form of the three body reaction, and raise a warning if the efficiency is set to a nonzero value.

[ischoegl]

@cory-kinney … the way things are implemented, ck2yaml is strictly a conversion tool. The duplicate checks are run after the file is converted. For the time being, my preference would be to issue warnings rather than errors (or implement some logic to be permissive about undeclared duplicates).