-
Notifications
You must be signed in to change notification settings - Fork 139
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
Comments
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? |
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 |
My proposal would be to write the carbon monoxide molecule as C#O to account for its dative bond using the adjacency list:
The reaction family
and
Once we have multiplicity as a species property the following adjacency lists will be resonance structures of the adjacency lists above:
and
|
I have now changed all carbon monoxide in the kinetic and thermochemistry libraries to
I have changed the reaction recipe of @shamelmerchant and @rwest: Can we close this issue? I think the species multiplicity part is a separate topic. |
What about other families? |
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? |
I haven't changed 2+2_cycloaddition_CO because its CO top node is
With that the old representation of carbon monoxide with
or
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? |
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. |
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? |
Sorry, I misread your adjacency list (not used to the extra columns yet) and see now that the new form |
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?... |
@shamelmerchant have you seen any 2+2_cycloaddition_CO reactions with carbon monoxide in one of your mechanisms? |
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. |
I have checked all kinetic families for Cjj=O leafs. @rwest and @shamelmerchant Should we move these rate rules for CO into a new |
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. |
Can we make a note to add this to documentation (like we did for "how to represent O2" when that changed)? |
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.
The text was updated successfully, but these errors were encountered: