Undeclared duplicate reactions detected

[Mark Kelly]

Hi all,

When loading in a mechanism file into Cantera I am getting 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
*******************************************************************************

I appreciate that these have the same reactants and products for the case when M = O2, however this wasn't an issue pre-Cantera 2.6.0. 

So I have 2 questions,

1. How was this dealt with before Cantera 2.6.0.

2. Is there any way to get around this/best way to deal with this? 

Thanks!

[Bryan Weber]

Hello,

This is a recent change, as you've noted. I suspect the answer is that previously the contribution of O2 was double-counted, but it may have been handled automatically and we made a change to require reactions to be more explicit in the input file. In any case, I believe the current solution is to set the collision efficiency of O2 to zero in the first reaction so that the contribution of O2 to the reaction rate is not double counted.

Hope that helps,

Bryan

[Mark Kelly]

Hi Bryan,

Thanks for your reply. It appears that the fix is to declare these reactions as "duplicates".

I was interested in how this calculation differs from previous Cantera versions so I performed a parameter study. 

I performed ignition delay time calculations at a range of conditions and I found the following:

1. Cantera 2.5.1 "double counted" O2 contribution. i.e., equivalent to declaring "O2:1" in the collision efficiencies. 
   
   
2. Using Cantera 2.6.0: Declaring "O2:0" in collision efficiencies results in considerable differences in the IDT compared to Cantera 2.5.1  (as expected as we are no longer double-counting")
   
   
3. ChemKin Pro IDT calculations mirror Cantera 2.5.1. Indicating that ChemKin also "double counts" as in Cantera 2.5.1. 
   

=>  it appears that the ideal fix for this issue is to declare the reactions as duplicate and to not add any terms to the collision efficiencies  (I deem this "ideal" as it replicates previous Cantera versions AND ChemKin Pro calculations).

See attached a rough excel spreadsheet of the results if you are interested.  

Thanks again for your help,

Mark

[Bryan Weber]

Hi Mark,

Thanks for investigating! I suspect the correct answer depends on the intent of the mechanism author (which we cannot know for sure without asking, obviously). Presumably, they validated their model with Chemkin, so "double counting" the O2 contribution is at least implicitly what they intended. However, from a physical standpoint, I think setting the efficiency to zero is more meaningful... it seems unlikely that mechanism authors would fit the rate of a reaction so that part of the O2 contribution was included in the M and part was in a separate reaction... or at least, that sounds like a lot more work :-D

In any case, I'm glad you found something that works for you!

Best,
Bryan

[Ingmar Schoegl]

There indeed has been a change on how these reactions are handled - both involve third-body collision partners, which Cantera now (correctly) detects. The recommended resolution is to mark these reactions as duplicates. For further information, see GitHub issues https://github.com/Cantera/cantera/issues/1251 or https://github.com/Cantera/cantera/issues/1278 and links therein. Best,

-ingmar-

[Bryan Weber]

Hi Ingmar,

Thanks for providing more context! I think #1193, https://github.com/Cantera/cantera/issues/1193#issuecomment-1035027205, gets directly to the recommendation. Insofar as it reproduces the previous behavior, I think it's fine to recommend this... however, as Mark in #1193 notes as well, the original intention of the mechanism author is ambiguous at best in these cases.

As I said above, I think there's a decent case that this was incidental on the part of mechanism authors (if any authors read this and want to chime in, please do!). As such, I wonder if Cantera should change the default, or at least warn users about what's happening here, and perhaps offer to automatically add the appropriate keywords to the YAML when converting from Chemkin? Probably worth considering as we pursue https://github.com/Cantera/enhancements/issues/132. We do need to be wary of adding to the already long list of warnings that are typically produced by Chemkin mechanism conversion, though...

I don't think we need to be slavishly devoted to reproducing ambiguously incorrect behavior in legacy, closed-source, software. But I'm also not keen to substantially disrupt the field if the results are as different as Mark (in this thread!) posted in his benchmark above. Unfortunately, I think people would assume that the legacy software was correct, and decide not to use Cantera at all...

Best,

Bryan

[Ingmar Schoegl]

I agree that mechanisms where this behavior is observed are ambiguous at best, as the reactions are clearly duplicates.

At the same time, at this point there has been a sufficient number of reports to warrant an update in Cantera's handling of these reactions. I believe that pursuing this in conjunction with https://github.com/Cantera/enhancements/issues/132 will be the most appropriate avenue.

-ingmar-

[Alberto Scomparin]

The following is to help anyone facing the same issue I had.

I encountered the error when using .cti files from external sources (in my case was the Shock and Detonation Toolbox data) and was able to solve it by editing the .cti as text file from, for instance:

three_body_reaction('H2 + M <=> H + H + M', [4.570000e+19, -1.4, 104380.0],

                    efficiencies='H2:2.5 AR:0.0 H2O:12.0')

to

three_body_reaction('H2 + M <=> H + H + M', [4.570000e+19, -1.4, 104380.0],
                    efficiencies='H2:2.5 AR:0.0 H2O:12.0',
                    options='duplicate')
for all reactions that give the error, which was not obvious to me.

Thank you to anyone pinpointing me in the right direction in previous comments and external links mentioned.

- Alberto