Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling CO in RMG-Py #31

Closed
shamelmerchant opened this issue Feb 18, 2014 · 16 comments
Closed

Handling CO in RMG-Py #31

shamelmerchant opened this issue Feb 18, 2014 · 16 comments

Comments

@shamelmerchant
Copy link
Contributor

With recent code changes in RMG-Py we now form both CO triplet and CO singlet in our mechanism.

To explain what is happening we first need to note the legacy way of handling CO.

In RMG-Java CO is represented as CO(T) and even though CO(S) is the more stable electronic state. We also assigned CO(S) thermo to CO(T) for example in DFT-QCI thermo library. The seed mechanism also have CO(T) and the families produce CO(T) only I think. Hence we were chemically wrong but consistent throughout which I think is OK.

Chemically CO(S) is the more stable state than CO(T).

in RMG-Py some libraries are imported from RMG-Java and have CO(T) while some nitrogen specific libraries have CO(S). The families in RMG-Py have no restriction and produce bot CO(T) and CO(S) .. if you were to load DFT-QCI as a thermo library now you would assign CO(S) thermo to CO(T). This hodgepodge can lead to weird mechanism getting formed and we should treat CO correct consistently.

@rwest
Copy link
Member

rwest commented Feb 18, 2014

If we can't really tell the difference between how they react, then we shouldn't pretend that we can tell them apart. Having two is certainly confusing. Will they behave differently in reaction families? Perhaps we should go with @bbuesser's suggestion to remove spin from the atom property and add to the species property. But would this need to be implemented in both -Py and -Java for us to prevent a diverging database?

@bbuesser
Copy link
Contributor

I think multiplicity as a species property shouldn't be a problem for Java-style. RMG-Java just needs a smart import function which shouldn't be too difficult. Tricky species would be poly-centered poly-radicals, but I think we do not have many, if any, in the database.

My proposal would be to

@bbuesser
Copy link
Contributor

My proposal would be to write the carbon monoxide molecule as C#O to account for its dative bond using the adjacency list:

CO
1 C 0 1 {2,T}
2 O 0 1 {1,T}

The reaction family 1,2-Insertion would have to be updated accordingly. Further we should add calculated thermochemistry to the primaryThermoLibrary for the two biradicals of CO.

COJJ(S)
1 C 2S 0 {2,D}
2 O 0  2 {1,D}

and

COJJ(T)
1 C 2T 0 {2,D}
2 O 0  2 {1,D}

Once we have multiplicity as a species property the following adjacency lists will be resonance structures of the adjacency lists above:

muliplicity = singlet

COJJ(S)
1 C 1 1 {2,D}
2 O 1 1 {1,D}

and
muliplicity = triplet

COJJ(T)
1 C 1 1 {2,D}
2 O 1 1 {1,D}

@bbuesser
Copy link
Contributor

I have now changed all carbon monoxide in the kinetic and thermochemistry libraries to

CO
1 C 0 1 {2,T}
2 O 0 1 {1,T}

I have changed the reaction recipe of R_Addition_COm accordingly in 8c656a9. It's title has been clarified in a comment on 8c656a9.

@shamelmerchant and @rwest: Can we close this issue? I think the species multiplicity part is a separate topic.

@rwest
Copy link
Member

rwest commented Feb 28, 2014

What about other families?
2+2_cycloaddition_CO springs to mind, but it can probably participate in many other reactions. Even if the groups don't need redefining everywhere, wont the locations of the relevant rate rules in the trees change? (eg. CO is no longer a child of R=R but of R#R)

@rwest
Copy link
Member

rwest commented Feb 28, 2014

Won't this new form Cj#Oj participate in H abstraction reactions to make Cj#OH containing an O with a triple bond and an H? Is that OK? What if it does radical recombination with CCCC[CH2] to make CCCCCO#C ? Would we have Benson groups for this species?

@bbuesser
Copy link
Contributor

I haven't changed 2+2_cycloaddition_CO because its CO top node is

1 *1 CO 0 {2,D}
2 *2 Od 0 {1,D}

With that the old representation of carbon monoxide with

1 *1 C 2S {2,D}
2 *2 O 0  {1,D}

or

1 *1 C 2T {2,D}
2 *2 O 0  {1,D}

has never participated in this reaction family. Therefore I thought it shouldn't change now. Do you know if the CO top node in this family is correct?

@bbuesser
Copy link
Contributor

Good point, I will check again the positions of the carbon monoxide leafs in the trees. I assume you have meant R#R for triple bond.

@bbuesser
Copy link
Contributor

I'm not sure about your last comment. R_Addition_COm has been, until now, forming Cjj=O and is now forming C#O (non-radical carbon monoxide with a triple bond), therefore C#O does not abstract hydrogen as a radical anymore. I thought that the rates have been measured or calculated most probably for ground state carbon monoxide C#O. We also can write that family to produce the excited Cjj=O. I think we have to check the rates of that family. What do you think?

@rwest
Copy link
Member

rwest commented Feb 28, 2014

Sorry, I misread your adjacency list (not used to the extra columns yet) and see now that the new form C#O is not a radical, so many of my comments don't make sense. I still think that changing how we represent something will require carefully going through every reaction family thinking about consequences and moving rate rules as appropriate (like when we decided O2 should be Oj-Oj instead of O=O)

@rwest
Copy link
Member

rwest commented Feb 28, 2014

And I'm not sure about 2+2_cycloaddition_CO top node. Even if it didn't match forward direction (because that's not how we represented CO) was it running in the reverse?...

@bbuesser
Copy link
Contributor

@shamelmerchant have you seen any 2+2_cycloaddition_CO reactions with carbon monoxide in one of your mechanisms?

@bbuesser
Copy link
Contributor

I have checked the references of the rates in R_Addition_COm and they are indicating ground state carbon monoxide. The calculations of MRH used singlet for CO and double for transition state in agreement with the new reaction recipe. There is also no definition of irreducible representation for the molecular orbitals which might indicate that CO was not calculated as a biradical singlet.

@bbuesser
Copy link
Contributor

I have checked all kinetic families for Cjj=O leafs. 1,2_Insertion, Disproportionation, R_Addition_MultipleBond contain leafs called CO_birad that were probably intended for carbon monoxide. Only 1,2_Insertion contains rate rules for CO_birad. The calcualtion descriptions are not very detailed but I assume as described above that they are for ground state carbon monoxide, although the adjacecny list had been written as biradical.

@rwest and @shamelmerchant Should we move these rate rules for CO into a new 1,2_Insertion_CO reaction family for non-radical species that have a lone pair and with an adjacent dative bond?

@connie
Copy link
Member

connie commented Oct 30, 2014

We have converted everything CO related to the singlet version at this point. CO is represented with a triple bond and lone pair on both carbon and oxygen. It should be in this format in both the families and existing reaction libraries.

@connie connie closed this as completed Oct 30, 2014
@rwest
Copy link
Member

rwest commented Oct 30, 2014

Can we make a note to add this to documentation (like we did for "how to represent O2" when that changed)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants