ReactionMechanismGenerator / RMG-Py

Python version of the amazing Reaction Mechanism Generator (RMG).
http://reactionmechanismgenerator.github.io/RMG-Py/
Other
383 stars 226 forks source link

Reaction appears in both Arrhenius and Chebyshev form in the same mechanism #741

Closed zjburas closed 1 year ago

zjburas commented 8 years ago

I noticed recently that when I run an RMG job with P-dep (input and output files attached), the two reactions shown below appear twice in both an Arrhenius and P-dep Chebyshev form. Both reactions are estimated by RMG (i.e., neither are from a library/seed mechanisms) and they are not labeled as duplicates. I can still run the mechanism in Chemkin and visualize it on the website, but sometimes if I try to merge this mechanism with another one I get an error due to the different rate expression forms. If I simply delete on of the forms, then the merge can happen.

Is there a reason that the same reaction should appear in both Arrhenius and Chebyshev form in the same mechanism? If so, the merge tool seems unaware that this is acceptable.

Reaction 1: ! Template reaction: H_Abstraction ! Flux pairs: O(11), OH(12); CH2O2(239), CHO2(57); ! Exact match found for rate rule (O/H/OneDeC;O_atom_triplet) O(11)+CH2O2(239)=CHO2(57)+OH(12) 1.700e+08 1.500 9.559

! PDep reaction: PDepNetwork # 754 ! Flux pairs: CH2O2(239), CHO2(57); O(11), OH(12); O(11)+CH2O2(239)(+M)=CHO2(57)+OH(12)(+M) 1.000e+00 0.000 0.000
TCHEB/ 300.000 3200.000 / PCHEB/ 0.010 98.692 / CHEB/ 6 4/ CHEB/ 2.258e+00 -6.953e-04 -4.838e-04 -2.685e-04 / CHEB/ 9.159e+00 2.178e-04 1.516e-04 8.409e-05 / CHEB/ 2.900e-01 1.990e-04 1.385e-04 7.681e-05 / CHEB/ 6.626e-02 8.873e-05 6.174e-05 3.425e-05 / CHEB/ 2.171e-02 3.737e-05 2.600e-05 1.443e-05 / CHEB/ 8.895e-03 1.768e-05 1.231e-05 6.834e-06 /

Reaction 2: ! Template reaction: Disproportionation ! Flux pairs: O2(2), HO2(15); C3H7(40), C3H6(164); ! Exact match found for rate rule (O2b;Cmethyl_Csrad) ! Multiplied by reaction path degeneracy 24 O2(2)+C3H7(40)=HO2(15)+C3H6(164) 1.735e+14 0.000 15.990

! PDep reaction: PDepNetwork # 262 ! Flux pairs: C3H7(40), C3H6(164); O2(2), HO2(15); O2(2)+C3H7(40)(+M)=HO2(15)+C3H6(164)(+M) 1.000e+00 0.000 0.000 TCHEB/ 300.000 3200.000 / PCHEB/ 0.010 98.692 / CHEB/ 6 4/ CHEB/ 1.064e+01 -1.009e+00 -1.107e-01 5.170e-03 / CHEB/ 1.259e+00 1.055e+00 2.825e-02 -2.697e-02 / CHEB/ 9.912e-02 1.122e-01 9.485e-02 4.995e-03 / CHEB/ -1.196e-02 -1.317e-01 1.078e-02 1.691e-02 / CHEB/ 2.804e-02 -6.321e-02 -2.468e-02 2.388e-03 / CHEB/ 3.333e-02 6.641e-03 -1.082e-02 -4.321e-03 /

input.txt chem_annotated.txt species_dictionary.txt

alongd commented 8 years ago

I agree that the DUP issue (see #566 ) is still not resolved. I'm still getting DUPs as well, even for two PDep reactions.

! Reaction index: Chemkin #2116; RMG #77263
! PDep reaction: PDepNetwork #8154
! Flux pairs: S(1185), S(1185); C2H4(20), C2H4(103); 
C2H4(20)+S(1185)(+M)=C2H4(103)+S(1185)(+M)          1.000e+00 0.000     0.000    
    TCHEB/ 1000.000  1600.000 /
    PCHEB/ 0.493     2.961    /
    CHEB/ 6 4/
    CHEB/ -1.495e+00   -3.392e-07   -7.354e-08   -1.080e-08  /
    CHEB/ 2.711e+00    1.295e-07    2.808e-08    4.125e-09   /
    CHEB/ -1.531e-02   -1.616e-09   -3.505e-10   -5.147e-11  /
    CHEB/ -8.790e-04   -2.245e-10   -4.868e-11   -7.150e-12  /
    CHEB/ -5.010e-05   -5.443e-12   -1.180e-12   -1.730e-13  /
    CHEB/ -7.798e-06   1.122e-12    2.437e-13    3.499e-14   /

! Reaction index: Chemkin #2118; RMG #77306
! PDep reaction: PDepNetwork #8155
! Flux pairs: S(1185), S(1185); C2H4(20), C2H4(103); 
C2H4(20)+S(1185)(+M)=C2H4(103)+S(1185)(+M)          1.000e+00 0.000     0.000    
    TCHEB/ 1000.000  1600.000 /
    PCHEB/ 0.493     2.961    /
    CHEB/ 6 4/
    CHEB/ -1.902e+00   -1.531e-07   -3.320e-08   -4.876e-09  /
    CHEB/ 2.820e+00    1.340e-07    2.905e-08    4.267e-09   /
    CHEB/ 2.408e-03    -2.653e-08   -5.753e-09   -8.450e-10  /
    CHEB/ 3.658e-04    2.523e-09    5.471e-10    8.036e-11   /
    CHEB/ -4.773e-05   1.151e-11    2.497e-12    3.675e-13   /
    CHEB/ -1.072e-05   -2.217e-11   -4.806e-12   -7.065e-13  /

(my ref: xa1436)

input.txt chem_annotated.txt species_dictionary.txt

jwallen commented 8 years ago

I think for once RMG is doing the correct thing (except for the merge tool).

It's acceptable to have Arrhenius and Chebyshev kinetics for the same reaction in a mechanism, as long as the Arrhenius comes from one of the A + B <=> C + D families (H_Abstraction, Disproportionation, etc.), since these families are by definition pressure-independent. The Chebyshev kinetics that come from a PDepNetwork such as A + B <=> X* <=> C + D would represent a different pathway that occurs in parallel to the pressure-independent pathway, so both should be in the mechanism. Therefore I would say that the merge tool needs to be updated to reflect that this is allowed.

In particular, I would expect R + O2 <=> HO2 + olefin reactions like @zjburas's Example 2 to be somewhat commonly encountered in combustion mechanisms, coming from Disproportionation and from R + O2 <=> RO2 <=> QOOH <=> HO2 + olefin. We should have considered these back in the day; perhaps we did not get around to properly documenting them.

Will comment on the DUP issue in #566, since I think they are distinct issues.

rwest commented 8 years ago

Thanks for chiming in, @jwallen. Glad you've not forgotten anything 😄 I agree that this sounds intended (or at least expected) behavior, apart from the merging tool. The #566 issue I had not thought through so carefully. Any thoughts on #736?

zjburas commented 8 years ago

Thank you @jwallen for the explanation.

icetwang commented 7 years ago

Have this issue got a solution now? I experienced a same issue. In the final mechanism, there are three reactions appearing in both Arrhenius and Chebyshev form. The Arrhenius forms are all from a library (FFCM). They are not defined as "DUPLICATE", and the three reactions are: CH3+HO2=CH3O+OH CO2+H=CO+OH O2+CH3=CH3O+O

I assumed RMG is right (high temperature, maybe be pressure dependent), so I delete these reactions from library and rerun RMG, but RMG will also not generate there reactions again (which is incorrect, CO2 even does not exisit). So I think it definitely need a solution from the source.

alongd commented 7 years ago

I'm looking at the duplicate reaction CH3 + HO2 <=> CH3O + OH reported by @icetwang , for example.

RMG generated the PDep network:

CH3OOH <=> CH3 + HO2
CH3OOH <=> H + [CH2]OOH
CH3OOH <=> OH + CH3[O]
CH3OOH <=> H + CH3O[O]
CH3OOH <=> CH2(S) + H2O2

and hence generated the PDep reaction CH3 + HO2 <=> CH3O + OH that passes (or skipping) the CH3OOH isomer.

On the other hand, the same reaction is reported by FFCM with a different rate, which is not PDep: image

RMG, of course, has no way of knowing the intention behind the reaction reported in the FFCM library (e.g., whether it represents a different path to the products or not), and in this case it included both in the Chemkin file.

Looking at the FFCM-1 project, for our understanding of this case, they took this rate from M.C. Lin 2001, which reports on the exact same path that RMG had discovered: image

(side note: RMG did not catch the CH2O + H2O products)

In Lin's paper I see reports of the PDep CH3OOH dissociation rate (including k_inf), but I didn't see the CH3 + HO2 <=> CH3O + OH rate. However, the point is that although FFCM did not report it in PDep form, this is the same pathway going through CH3OOH as well. They probably took the 1 atm value and adjusted it within the uncertainty boundary to fit experimental benchmarks.

For this particular case, one of the reactions in the Chemkin file should be deleted, as @icetwang did. I agree that the FFCM one should be deleted, since his model is generated for high pressures (10-40 bar).

But we should find a more permanent fix. We could, perhaps, create a "modified" FFCM library with PDep terms where appropriate, but this will be a lot of work (and what about other libraries?), and won't be optimized for NG like FFCM is...

github-actions[bot] commented 1 year ago

This issue is being automatically marked as stale because it has not received any interaction in the last 90 days. Please leave a comment if this is still a relevant issue, otherwise it will automatically be closed in 30 days.