O2(2) + CH2(T) reactions from pdep network - speeding up flame speed for fluoromethane.

[Nora-Khalil]

trafficstars

Hi all,

Looking for help on this issue with RMG's estimated rates for reactions between O2(T) and CH2(T), specifically O2(2) + CH2(T) <=> H + [O]C=O

For context, I started to rebase two years worth of RMG-database additions pertaining to PFAS chemistry onto my updated main branch of RMG database.

To check that things are working properly, I build a model for fluoromethane (CH3F) and test the flame speed. When I generate and test the flame speed of the model on my outdated development branch, the flame speed looks good! However, after rebasing my changes onto an updated main branch, the CH3F flame speed is ~30 cm/s higher than it should be. : (

This jump in flame speed is triggered by a new library I have added, ANL_Brown_pdep, which includes new calculated rates from our recent publication. This library includes an initial decomposition of CH3F into HF + CH2(T). Following this initial decomposition, RMG then reacts CH2(T) + O2(2) in a pdep network to get H + [O]C=O. On my development branch, this rate was a lot lower. On the rebased branch, this rate is a lot higher (due to some new training data from others).

Even if I don't make any changes to the kinetic families on the updated main branch and simply introduce my ANL_Brown_pdep library, the estimated O2(2) + CH2(T) <=> H + [O]C=O rate still leads to a grossly high flame speed. It seems like, on the main RMG-database branch, this reaction rate is a lot higher than it should be (and we become aware of this high rate only when the ANL_Brown_pdep library opens up that initial pathway of CH3F <=> HF + CH2(T).

CH2(T) + O2(2) is a very well studied pathway; our RMG libraries (and the literature) include many reactions starting with CH2(T) + O2(2) (see below), but none with products of H + [O]C=O. I think because it's concluded to be not important...

Has anyone else experienced this issue with the pdep networks that react O2(T) + CH2(T)?

Thinking of ways to get around this. One is to find the reactions that make up the pdep network that produced O2(2) + CH2(T) <=> H + [O]C=O, then add in training reactions to the appropriate family to correct these estimates.

@rwest might have other thoughts, so we can all discuss here.

[rwest]

I think this is what the Pdep network is looking like network.pdf though I had to manually edit the network3_4_mod.py.txt file because of the bug mentioned in https://github.com/ReactionMechanismGenerator/RMG-Py/pull/2791

If I'm understanding this correctly, the problem is:

1. RMG is using net rates for this PDep network from the library, when they are given, which is the correct thing to do and not the problem.
2. RMG is then also taking some net rates from evaluating this PDep network itself, when they are missing from the library. This would sometimes be the correct thing to do, if the library were incomplete. But in this case we think they are missing from the library because the library authors are implicitly stating the rate is negligible. RMG's estimate is then too high. eg. O2 + CH2(T) <=> H + OCHO, seems to be accelerating your flames?

Solutions could be:

1. help RMG estimate the rate correctly, perhaps by adding training reactions to the database for all the important path reactions in the network? do we know which are poorly estimated currently? I think you had at least identified which had changed much in the last ~year? Is the thermo all looking OK?
2. forbid, somehow, RMG from adding extra reactions from this Pdep network or PES.

What is the best solution? Is there an easier solution? What is a good general solution? How general is this problem?

cc @mjohnson541

[mjohnson541]

Generally these issues are easiest to debug in the network explorer tool, because you don't have to rerun all of RMG to generate the network.

Currently RMG pdep operates based on the premise that pdep/RMG estimates give a good answer, but the user might give a better answer for some reactions while missing other reactions. Here it breaks because pdep/RMG estimates aren't giving a good answer and is trying to fill in missing other reactions. I see this as the pdep result of a poorly estimated rate coefficient so I wouldn't expect this kind of issue to be uncommon when doing less studied chemistry with smaller molecules. I do think poorly estimated pdep reactions are easier to deal with than missing reactions we don't know about so I think this configuration is the right choice.

The intended proper solution to this is to improve the RMG estimates for the involved rate coefficients. However, it would be nice if we could tag PESs in the input file as complete. Adding the option to the reaction library might be easier to implement (which would add a hacky, but simple way to fix this), but leaving that tag in a reaction library would be counter to the premise above.