Degeneracy on asymmetrical groups (1+2_Cycloaddition)

[nyee]

For the reaction between singlet carbene and propene in 1+2_Cycloaddition, RMG gives two different kinetics for [ mb_db_monosub_Nd , carbene ] and [ mb_db , carbene ]. Here's the adj List for mb_db_monosub_Nd

mb_db_monosub_Nd
1 *1 Cd 0 {2,D} {3,S} {4,S}
2 *2 Cd 0 {1,D} {5,S} {6,S}
3 H 0 {1,S}
4 H 0 {1,S}
5 H 0 {2,S}
6 {Cs,O} 0 {2,S}

The problem is that RMG will label propene in two different ways:

propene ----> Hits mb_db_monosub_Nd
1 *1 C 0 {2,D}
2 *2 C 0 {1,D} {3,S}
3 C 0 {2,S}

propene ----> Does not hit mb_db_monosub_Nd and falls up to mb_db.
1 *2 C 0 {2,D}
2 *1 C 0 {1,D} {3,S}
3 C 0 {2,S}

I'm sure this problem shows up in some other families as well. It is essentially caused by an asymmetrical group having degeneracy. Is it better to hard code a fix into RMG or modify the tree so that mb_db_monosub_Nd is a union of two groups that includes both? Modifying RMG code sounds painful and will probably lead to an onslaught of bugs. On the other hand, modifying the trees is going to be really tedious and creates another obstacle for people adding rules.

[rwest]

What's the problem here? I can imagine the radical attacking the C1 could have a different transition state from the radical attacking the C2, and thus have a different rate. The overall reaction ends up being the same, but the total rate would be the sum of the two elementary rates. (If it was symmetrical, we would again match it both ways around, but when summing the two rates, would recognize they were the same, and double the A factor (degeneracy).)
Is the problem just lack of data for one of the rates?

[nyee]

Thanks Richard, your comment helped me clarify the issue in my head. In the majority of cases, what you said it correct, but I think in this case the transition state should be the same.

If I understand's Bill's explanation, the pi electrons from the propene go directly into carbene's empty orbital. No matter which one is *1 and *2, the transition state is going to be two partial bonds going to carbene. In that case, we would want RMG to find mb_db_monosub_Nd twice.

[rwest]

OK. That helps. What would you want the rate to be (and what groups would you want it to match) for but-2-ene CC=CC? Would the rate be different from propene C=CC? (if so, we can't have it match the same groups)

[nyee]

I think for but-2-ene we would want it to match mb_db_twocdisub_Nd twice. We would want propene to match mb_db_monosub_Nd twice. Sorry for the long names, these are actually pulled from the tree.

Maybe a special case needs to be programmed for this family when generating kinetics.

[rwest]

It seems thy when I wrote

when summing the two rates, [it] would recognize they were the same, and double the A factor (degeneracy).)

I was describing RMG-Java, and according to issue #142, RMG-Py does something different (and wrong)

[nyee]

Richard,

I was trying to implement the suggestion you had at last RMG meeting, where I would assign carbene x mb_db (the unwanted duplicate rule) with kinetics where A=0.

However, I need to make a dummy rate for every single node of carbene's tree to be completely general. While admittedly there's only 7 nodes right now, I'm wondering if this is really the best solution. If I do it this way, when others change the database in the future, they'll have to know to add new dummy rates.

I'm exploring the option of hard-coding a special case right now because that is the only option that doesn't require special upkeep of the database in the future.

[rwest]

...but wouldn't it then require users updating the database to know that something special has been hard-coded into the software? Otherwise they may try to add rates in places that are never used, or something. If the family is special, there is no getting away from the fact that someone updating the database should be aware that it's special, and should do the right thing, with appropriate care. I'm not sure any solution avoids this.

I do now see your conundrum though, and it's something I hadn't really thought through: you need a rule for everything in the other half of the tree, to avoid the averaging scheme. Hmmm. Tricky.

[nyee]

The fix I'm trying to put in will only delete the duplicate kinetics in hard-coded families. I'll have it check to see that the one rule's nodes are either children of or the same as the other's.

You're correct that (mb_db, carbene) will never be hit, but that is because of that particular tree's structure (having an exhaustive children set) and not because of the weirdness of the reaction family. I think once I put in the above fix, it will behave just like any other family, except the degeneracy of the rules will be 2x that of other families. Am I correct in saying: we don't actually document the degeneracy other than assuming that people are dividing A-factor by the correct amount when entering in new rules?