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

Question about C2H4+O_Klipp2017 library #441

Open
xiaoruiDong opened this issue Sep 28, 2020 · 4 comments
Open

Question about C2H4+O_Klipp2017 library #441

xiaoruiDong opened this issue Sep 28, 2020 · 4 comments
Assignees

Comments

@xiaoruiDong
Copy link
Contributor

This is a library I previously used in the model generation, but some analyses make me reconsider this choice. The general question is how we should use this library?

Here are some preliminary investigation and thoughts:

This reaction library is compiled according to http://dx.doi.org/10.1016/j.proci.2016.06.053. The pathways in the paper are calculated by QM with decent LoT. However,

  • There are 3 reactions have really rough estimations:
  1. C2H4 + O <=> C2H3 + OH
  2. C2H4 + O <=> CH4 + CO
  3. C2H4 + O <=> C2H2 + H2O
    These reactions have a small contribution to the total C2H4 + O flux, thus they are not well studied in the paper, and Alon simply assigned 1e7 cm^3/(mol*s) when creating this library. We may not want to use these values.
    For reaction 1, slightly better value can be found in other libraries / the training reactions, which is calculated by TST theory from a 1987 paper.
    For reaction 2 and 3, no other values cannot be found in the RMG database (since they are not elementary reactions)
  • More problematically, rates contained are 'rates of channels' instead of 'rates of elementary reactions' (except C2H4 + O <=> C2H3 + OH). Despite whether used as a seed mechanism or a reaction library, it will always introduce duplicated pathways.
    For example:
    C2H4 + O <=> CH3 + HCO is actually C2H4 + O <=> [CH2]CH2[O] <=> CH3[CH][O] <=> CH3 + HCO. Those intermediate steps can be found by RMG, though rate coefficients are just rate-rule estimations. When using C2H4+O_Klipp2017 family, we will have a stepwise pathway and an overall reaction simultaneously in the mechanism, and double count the overall flux. (Note, it's not like stepwise+well-skipping reactions). Other reactions suffer from the same issue.

My thought is that we probably should stop using this library. Maybe even remove it, to avoid people accidentally use this library. Happy to hear other people's opinions.

@xiaoruiDong xiaoruiDong self-assigned this Sep 28, 2020
@alongd
Copy link
Member

alongd commented Sep 28, 2020

It's very weird that the rate coefficients in this paper/library are Arrhenius and not in a PDep form.
You can try adding the elementary_high_p flag as True to elementary reactions so that RMG uses them when it constructs networks. For non-elementary reactions, either remove them or set the allow_pdep_route flag to False.

@mjohnson541
Copy link
Contributor

So I think this is related to the philosophy of #301. I don't think in general we should be adding in rates that aren't in a paper to the library associated with the paper, but we should build separate libraries that compile other reaction libraries and rates to get better mechanism generation outcomes. I think the second issue is purely logistical and probably satisfactorily resolved with allow_pdep_route=False as @alongd suggests.

@xiaoruiDong
Copy link
Contributor Author

xiaoruiDong commented Sep 29, 2020

@alongd, thank you for letting me be aware of elementary_high_p / allow_pdep_route.
@mjohnson541 thank you for letting me know your thoughts.

I have some follow-up questions regarding allow_pdep_route. I don't think I fully understand how this argument works:

  1. Is this a feature only in the Pdep model generation or both Pdep and high-P-limit model generation?
  2. Is this a feature that works only for using C2H4+O_Klipp2017 as a reaction library, or it also works when using it as seed mechanism.
  3. The default value of allow_pdep_route is False. So, I assume that with the current reaction.py file where this argument isn't explicitly defined, allow_pdep_route=False is used in my model generation?
    ""
    Quote: allow_pdep_route: If set to True and RMG discovers a pressure-dependent reaction with the same reactants and products, the latter will be considered in addition to the library reaction. This is useful for cases when more than one pathway connects the same reactants and products, and some of these pathways are well-skipping reactions. If set to False (the default value), similar network reactions will not be considered in the model generation.
    ""
  4. In one of my model generation, I used C2H4+O_Klipp2017 as the seed mechanism, and I didn't turn on Pdep. I got a mechanism with both reactions in C2H4+O_Klipp2017 (channel reactions, e.g., C2H4+O = CH3 + CHO) and all stepwise reactions. see the following figure:
    image

Since allow_pdep_route=False as default, I don't expect those stepwise reactions to be generated, right?
Think one step further, even if those stepwise reactions are not generated, RMG will still generate reactions like C2H4 + O <=> [CH2]C[O] <=> C1OC1 (if significant), right? Then things are still messed up. According to the paper, if we sum up all fluxes belonging to reactions of C2H4+O_Klipp2017, this should be the total flux out of C2H4 + O. But now, we will have another channel with comparable flux.

I tried my best to describe what is going on, but let me know if it is still hard to understand. Due to my little experience in generating Pdep models, please also let me know if there is something really wrong with my thoughts.
Many thanks, guys.

@alongd
Copy link
Member

alongd commented Sep 29, 2020

I agree that there might still be some problems with the current approach using these flags.
(1. and 3.) I need to look at the code to be certain, but I think that these flags are only valid for PDep kinetics. This library has Arrhenius type kinetics (just high-P), so there's no effect.
(2.) I don't know if it functions the same for a seed library, I think so (and it should), but not sure.
(4.) I would also expect to get double routes in a situation like this w/o PDep. But w/o PDep there are more severe problems to worry about.

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

3 participants