Closed shamelmerchant closed 9 years ago
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:
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}
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 8c656a9c1c5798086c1abea43a37fb2fee40434b. It's title has been clarified in a comment on 8c656a9c1c5798086c1abea43a37fb2fee40434b.
@shamelmerchant and @rwest: Can we close this issue? I think the species multiplicity part is a separate topic.
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)
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
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?
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 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)
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. 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?
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.