Kinetics may not be taken from PrimaryReactionLibrary (aka PrimaryKineticsLibrary) for reactants/products with resonant structures

[gmagoon]

Background: There are two ways of representing the ketenyl radical HCCO. The two resonance forms are:

ResonanceFormA 1 C 1 {2,D} 2 C 0 {1,D} {3,D} 3 O 0 {2,D}

and

ResonanceFormB 1 C 0 {2,T} 2 C 0 {1,T} {3,S} 3 O 1 {2,S}

Problem: I made a PrimaryReactionLibrary with the following reaction: H + HCCO = CH2CO 1.51E14 0.0 0.0 0.0 0.0 0.0 The reaction should be generated by RMG's templates (in particular, R-recombination or its reverse, bond dissociation.) However, these kinetics weren't being used by RMG, which was instead using its database estimates. It appears that this is related to the multiple resonance forms for HCCO. In particular, it seems that the function isSpeciesListEquivalentToChemGraphListAsGraphs() is not correctly recognizing the two resonance forms as being equivalent (see calls at http://github.com/GreenGroup/RMG-Java/blob/165e221bcc1e07195d2ca12a7145e0a25a188c2c/source/RMG/jing/rxn/ReactionTemplate.java#L621 and http://github.com/GreenGroup/RMG-Java/blob/165e221bcc1e07195d2ca12a7145e0a25a188c2c/source/RMG/jing/rxn/ReactionTemplate.java#L624 ).

I'm not immediately sure what the best way to fix this would be...maybe some sort of additional iteration over resonance isomer chemgraphs in the method isSpeciesListEquivalentToChemGraphListAsGraphs() ?

Thanks to Shamel for identifying the underlying issue here.

Workaround: My temporary workaround for this issue was to place ResonanceFormB in the ForbiddenStructures.txt. (I also needed to change the Dictionary.txt definition for s00003017 (HCCO) in the GRI-Mech3.0 PrimaryThermoLibrary from ResonanceFormB to ResonanceFormA in order to get the thermo correctly read from the PrimaryThermoLibrary.)

Another issue I came across in looking at this (maybe a separate bug?): Debug mode suggests that although both forward and reverse reactions (H + HCCO -> CH2CO and CH2CO -> H + HCCO) are generated in the process of reading in the PrimaryReactionLibrary, the two reactions are given the same (forward) kinetics, at least as of this point in the code: http://github.com/GreenGroup/RMG-Java/blob/165e221bcc1e07195d2ca12a7145e0a25a188c2c/source/RMG/jing/rxnSys/ReactionModelGenerator.java#L4352 . Maybe this is corrected later, however?

[gmagoon]

PS...I forgot to mention in my description above that I was specifying ResonanceFormA for HCCO in the PrimaryReactionLibrary dictionary (and condition.txt file)

[rwest]

I think we should be matching against all resonance isomers when looking for things in the primary libraries - either thermo or kinetics. As far as I understand it (please correct me if I'm wrong here) resonance isomers are essentially just different ways of representing the same species in adjacency list (chemgraph) syntax.

I think in some places we generate all the resonance isomers, identify the most stable according to our estimates, and store that form. This saves having to iterate over all the others, with obvious speed benefits. This is probably why many places in the code don't iterate over resonance forms - they assume things are always in the stablest. Perhaps we should just do the same when reading in the primary thermo and kinetics library dictionaries?

[gmagoon]

@rwest: Yes, resonance isomers are different chemgraphs representing the same species. The problem with just using the most stable form is that this may not be the form that should be used for the kinetics. For example, in this case, if we just stored ResonanceFormB, RMG's R-recombination wouldn't identify the reaction H+HCCO->H2CCO (it would instead identify H+HCCO->HCCOH).

[rwest]

OK, so we always need to store all resonance isomers, so that we can generate all the possible reactions. (I presume the 'only store the stablest form' I was thinking of was referring to the thermochemistry, not the chemgraphs).

In that case, I would say we should be checking against all the resonance isomers when looking in the primary libraries?

[gmagoon]

Follow-up on the "Another issue I came across": I tried switching the order of the reaction in my PRL, and the Chemkin output changed accordingly. So, if there is an issue with both forward and reverse having same kinetics, it does not seem to be causing any problems, at least with the Chemkin output.

[gmagoon]

"In that case, I would say we should be checking against all the resonance isomers when looking in the primary libraries?"

Yeah, I'm thinking this will probably be the type of approach we want to use.

[mrharper]

BUG FIX: Primary Reaction/Kinetics Library & resonance structures

When RMG checks each new reaction against the Primary Reaction (soon to be Kinetics) library, the algorithm now iterates over all possible resonance structures of the given chemgraph (if applicable). This was the suggested solution of Greg and Richard.

I've tested this against the example Greg mentioned in the Issue tracker and the problem has been resolved.

Closed by 8ef704205d46d07a5af4cd680f294f61045f291b