R_Recombination family not constructing averaged rate rules

[jwallen]

In trying to figure out how RMG-Java constructs its crazy average-of rate rules, I came across an unexpected issue: no average-of rate rules are being generated for R_Recombination. Stepping through the recursive function, we find that this occurs because the top-level node is identified as having a nonzero rank. (Presumably whoever coded this believed that an averaged rate rule was better than a rate rule with a rank of zero.) However, looking at the database, the top-level rate rule for R_Recombination clearly is listed with a rank of zero.

The end result is that, unlike other families, the R_Recombination family is using the top-level rate rule as given in the database (rather than as an average), and doing so much more often.

[rwest]

This could be intentional - perhaps the top level node is better (or at least safer) guess than the result of a crazy average. I would carefully check the consequences in terms of chemistry before committing a "bug fix" here.

[jwallen]

Okay, the cause is commit cf2dc832db55e01711f1a617174e06eac9128010, in which @mrharper added a new Y_rad + Y_rad node at the bottom of the rate library with the same rate as the existing Y_rad + Y_rad node, but with a rank of 1. According to Mike, this is supposed to fix a problem in which R_Recombination high-pressure rates were way too fast. Sure enough, the Py vs. Java comparisons I'm looking at show the Java estimate as slower than the Py one. What's not clear from the commit message is if he (or any of us at the time) understood that this was effectively turning off all averaged rate rules for this family.

Also new (to me at least) was the way that duplicate rate rules are handled: it's more complicated than I originally thought.

I won't close this issue yet because I feel it might be worth discussing at an RMG meeting, if for no other reason than to let everyone know how the RMG-Java kinetics estimation actually works in practice.

[rwest]

I certainly wouldn't have guessed that preventing averaging at the top level node prevents all averaging for that family. At least not without thinking hard.

[jwallen]

There's also the question of which child nodes come into play when generating an average. For reactants A and B with children A1, A2 and B1, B2, respectively, it looks like only (A1,B1), (A1,B2), (A2,B1), and (A2,B2) can contribute to the averaged value for (A,B), and not (A,B1), (A,B2), (A1,B), or (A2,B), despite the latter set having a smaller "distance" from (A,B). However, this changes if either A or B is a leaf (i.e. has no children). This bit is at least consistent with how it reads in Jing's thesis. Also interesting is that the averaging function seems like it doesn't then generate any averaged value at all for (A,B1) etc. So there's a few algorithmic questions to be answered.

Unfortunately, I fear our group additivity estimates are still doing worse than these, at least for the reactions involved in alkyl + O2 systems, which is what we've been looking at recently. (Though using the current website is not fair because the barrier height corrections are not currently being applied to the group additivity estimates when called via Django.)