Substitution_O giving ERROR: Couldn't find the rate constant for reaction...

[rwest]

Running the butane_pruning example on jwallen@7f4c395dcb2eab3674a6dbdc110de12784d991c2 4.0 branch I get a lot of ERROR: Couldn't find the rate constant for reaction messages from the Substitution_O family:

Created new reverse Substitution_O reaction: C4H10O4(828) + C3H6JJ(305) --> C4H9O2J(1637) + C3H7O2J(755) ERROR: Couldn't find the rate constant for reaction: SPC(1637)+SPC(755)=SPC(828)+SPC(305) with Substitution_O Created new reverse Substitution_O reaction: C4H10O4(828) + C3H6JJ(305) --> C4H9O2J(1637) + C3H7O2J(755) ERROR: Couldn't find the rate constant for reaction: SPC(1637)+SPC(755)=SPC(828)+SPC(305) with Substitution_O

Not sure what this signifies.

[jwallen]

Looking at rateLibrary.txt, I see that we only have rate rules for the leaves, which makes sense since all of them come from quantum chemistry calculations involving real reactions. We haven't provided any generic rules, particularly none for the most generic top-level nodes. The rate rule averaging scheme will presumably fill in some of these rules by averaging, but my understanding of the current implementation is that it is not exhaustive, so there will likely be gaps (hence the error).

Shorter version: Adding a generic rate rule for the top-level nodes should make the error go away. I will test this.

[jwallen]

The above turned out to be incorrect. The actual reason is that Substitution_O is its own reverse, but the hardcoding of swapping labeled atoms 2 and 3 after applying the reaction recipe had not been implemented. Adding this change removes almost all of the errors.

(Adding the top-level generic rate rule had no effect, so I'm not going to keep it, especially since it isn't very representative of the wide range of k(T) values in the library.)

[jwallen]

Addendum: Earlier I said that there were still a few of these error messages remaining in the RMG log, even with the above fix. Running with Substitution_O in RMG-Py - which crashes at this error and therefore forces you to deal with it - reveals why: the template matches R-O-R' + R": -> R-O-R". + R'. in only the forward direction, even though this family is its own reverse. To fix the remaining lines we need to either (1) forbid R":, and only allow R"., or (2) allow radical sites adjacent to the ether oxygen. If we do (2) we match more reactions, but the rate estimates are likely to be poor because all of the current rate rules are for (1). Thus I'm leaning towards (1), at least in the short term.

[rwest]

Hmmm. Choice (1) is essentailly estimating the rates of the other reactions to be zero. Is this a better or worse estimate than the poor estimate given by choice (2)? Could we make up an estimate that's better than both?

[jwallen]

Giving a poor estimate will at least force someone to deal with it if the poor estimate causes that reaction to become sensitive in their model. This is probably better than just arbitrarily assuming a negligible rate. (That's assuming they don't just cheat and turn off the family entirely, of course.) The reaction I discovered this for involves conversion of O: to HO2, which I suppose could affect your ignition delays.

There is also a chemical question of whether the transition state is sufficiently different for R": that it should be considered a separate family. I don't know enough about this chemistry to answer that.

[rwest]

I lean towards including it, but fear that shipping a 4.0 release that produces crazy rates will not help RMG's credibility. Maybe Bill can make up a top level number for us (unless someone has a better way to get one? Who made this family in the first place?)

[jwallen]

One challenge in making up rules for this family is that the kinetics are quite different for the different functionalities (e.g. water vs. alcohol vs. ether vs. peroxyether). I was able to impose some order (back when I thought the problem was missing generic rate rules) by grouping the rules by element for R' and R", but even then the rates vary over several orders of magnitude. (Aside: This could be an interesting stress test for the kinetics group additivity method, especially since we know the real reactants and products that all the ~130 rules came from.)

At any rate, I will try (2) with my model at least without adding any new rules and see what happens.

[jwallen]

Okay, running my DIPK model at 637a0034f56c8b5318731997d8e3bec7baba808d shows no change in the generated model other than adding 15 reactions that now no longer give the "Couldn't find the rate constant for reaction" error message. This probably isn't that surprising, since none of the original Substitution_O reactions were sensitive in my model, so I wouldn't generalize from this. All I can say is that is doesn't appear to be an immediate problem for me. :P

More importantly, I can now move on to the next bug in getting RMG-Py to run my DIPK model.