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

Spin states in libraries is confusing? #184

Closed
shamelmerchant opened this issue Feb 15, 2014 · 7 comments
Closed

Spin states in libraries is confusing? #184

shamelmerchant opened this issue Feb 15, 2014 · 7 comments
Labels
abandoned abandoned issue/PR as determined by actions bot stale stale issue/PR as determined by actions bot

Comments

@shamelmerchant
Copy link
Contributor

I noticed with my N jobs I get two CO molecules most of the CO in Dean and Bozzelli library is singlet and the one in EFRC library is triplet?

What is it generally? I know in java we assumed it to be triplet but gave both of them the same thermo. Now with Beat changes we have to carefully consider this otherwise our models will have species in multiple spin states! Similar story with CH is it a quartet or doublet (Aaron says doublet is the stable state)

If any one could help me understand this it would be great. I think we need a careful evaluation of our libraries also.

@bbuesser
Copy link
Contributor

I think in the current RMG, storing multiplicity as an atom property, this affects only 1-centered bi- and triradicals (also the only quadradical, the carbon atom). Each multiplicity has its own energy minimum and therefore its own thermochemistry and therefore is a separate species. I have tried to calculate and include ATcT thermochemistry of the most important bi- and triradicals into the primaryThermoLibrary. I think the question it not Is the quartet or doublet state of CH more stable? We need a quartet and a doublet CH species. As long as we have the correct thermochemistry the reaction equilibriums will define how much of each multiplicity we will obtain.

To make this really perfect we need a function that ensures spin conservation when generating new reactions plus we need to track the correct multiplicity of 2-centered radicals and for that we need the multiplicity as a species property.

Carbon monoxide (CO) is a special case in RMG (so far). It is treated as a double bonded singlet biradical and therefore RMG now thinks it could also be a double bonded triplet biradical too. Although the ground state that we most probably have in our libraries is the triple bonded singlet without radicals, with the current atoms types the singlet biradical was the closest to that triple bonded electron configuration possible. Therefore this was used by the former developers in all libraries so far, I'm not sure about EFRC, we need to check where the library comes from.

@enochd
Copy link
Member

enochd commented Feb 15, 2014

The CEFRC CO should also be singlet. What indication do you have that it's triplet? CH should also be doublet. These are the ground state electronic configurations. Both species can undergo excitation to higher states (especially under combustion conditions), but these species are typically not included in models

@shamelmerchant
Copy link
Contributor Author

I think in EFRC it might be just a transcribing issue since Java stores it as a triplet. My main concern is the mix that we have created and that we should go and systematically correct the spin states. Some reactions in Dean and Bozzeli library clearly do not follow spin conservation ( I am not sure when are such occurrences possible).

@bbuesser
Copy link
Contributor

we have to be careful with Dean and Bozzeli, there can be reactions that involve spin flips. I have tried to follow their book chapter as closely as possible. But typos can occur for sure.

@bbuesser
Copy link
Contributor

There is not need to reimport the libraries based on the Dean and Bozzelli book chapter because they were never intended for Java format.

@rwest
Copy link
Member

rwest commented Feb 18, 2014

@github-actions
Copy link

This issue is being automatically marked as stale because it has not received any interaction in the last 90 days. Please leave a comment if this is still a relevant issue, otherwise it will automatically be closed in 30 days.

@github-actions github-actions bot added the stale stale issue/PR as determined by actions bot label Jun 22, 2023
@github-actions github-actions bot added the abandoned abandoned issue/PR as determined by actions bot label Jul 22, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abandoned abandoned issue/PR as determined by actions bot stale stale issue/PR as determined by actions bot
Projects
None yet
Development

No branches or pull requests

4 participants