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

Inconsistency between TROE formula and code when T** is zero. #683

Closed
ghost opened this issue Aug 8, 2019 · 6 comments · Fixed by #741
Closed

Inconsistency between TROE formula and code when T** is zero. #683

ghost opened this issue Aug 8, 2019 · 6 comments · Fixed by #741
Labels

Comments

@ghost
Copy link

ghost commented Aug 8, 2019

Cantera version

2.3.0

Operating System

Linux Ubuntu18.04 64bit

Python/MATLAB version

3.7

Expected Behavior

When T** is not given, the default value is 0.0, as description in https://cantera.org/science/reactions.html . Then the last term exp(-T**/T) ==1

Actual Behavior

When T** is not given, the last term exp(-T**/T) is ignored so this term is actually zero.

Steps to reproduce

  1. With a very small T**
cti_def = '''
    ideal_gas(name='gas', elements='O H C',
              species='gri30:H CH2 CH3 O2 H2O CO2',
              reactions='all',
              options=['skip_undeclared_elements', 'skip_undeclared_species', 'skip_undeclared_third_bodies'],
              initial_state=state(temperature=2000, pressure=101325))
    #  Reaction 50
falloff_reaction( "H + CH2 (+ M) <=> CH3 (+ M)",
         kf = [6.00000E+14, 0, 0],
         kf0   = [1.04000E+26, -2.76, 1600],
         falloff = Troe(A = 0.562, T3 = 91, T1 = 5836, T2 = 1e-10))
'''
gas = ct.Solution(source=cti_def)
gas.TPX = 2000,1e6,[1,1,1,1,1,1]
gas.net_rates_of_progress
## output array([6.57248322e+10])
  1. Without T**
cti_def = '''
    ideal_gas(name='gas', elements='O H C',
              species='gri30:H CH2 CH3 O2 H2O CO2',
              reactions='all',
              options=['skip_undeclared_elements', 'skip_undeclared_species', 'skip_undeclared_third_bodies'],
              initial_state=state(temperature=2000, pressure=101325))
    #  Reaction 50
falloff_reaction( "H + CH2 (+ M) <=> CH3 (+ M)",
         kf = [6.00000E+14, 0, 0],
         kf0   = [1.04000E+26, -2.76, 1600],
         falloff = Troe(A = 0.562, T3 = 91, T1 = 5836))
'''
gas = ct.Solution(source=cti_def)
gas.TPX = 2000,1e6,[1,1,1,1,1,1]
gas.net_rates_of_progress
## output array([2.8516357e+10])

Comment

According to CHEMKIN's source code and theory guide, this behavior of cantera is consistent with the implementation of CHEMKIN but it is inconsistent with the cantera's document, CHEMKIN's theory guide and Troe's paper.

However, I do not know which is correct. It may influence the behavior of Weiyao's 89 species, 683 reactions reduced mechanism for kerosene.

@bryanwweber
Copy link
Member

@chengdi123000 Can you reproduce this behavior with the master branch?

@speth
Copy link
Member

speth commented Aug 13, 2019

I don't think there are any relevant changes here between Cantera 2.3.0 and the current master branch.

There are two cases here, both of which have some issues. However, I have concerns with the validity of 0 or near-zero values for T**. The original paper by Troe states that "Fcent decreases from Fcent = 1 at 0 K with increasing temperatures, before it increases at very high temperatures". However, If T** is set to 0, then the low-temperature limit for Fcent is 2, not 1.

Case 1: T** omitted

  • Cantera omits the term exp(T**/T) from the expression for Fcent.
  • This is consistent with the implementation of Chemkin 2 and the Chemkin Input Manual
  • This is not consistent with the Cantera "science" documentation.

Case 2: T** given as 0.0

  • Cantera omits the term exp(T**/T) from the expression for Fcent. (same behavior as when T** is omitted)
  • This is not consistent with the Cantera "science" documentation.
  • This is not consistent with the implementation of Chemkin 2 and the Chemkin Input Manual

While the inconsistencies should be addressed, I think that we should warn if T** is specified as 0, since I suspect it is an error and what was intended is actually Cantera's current behavior of omitting the term.

@ghost
Copy link
Author

ghost commented Aug 19, 2019

I agree with @speth

In some mechanism in chemkin's format, the T** is assigned a very large negative number such as -10e30 to ensure the last term exp(T**/T) is essentially zero.

I think keeping consistency with CHEMKIN and modifying the description in document is the best approach to resolve this issue.

FYI, here is the description of TROE coefficients in Input Manual of CHEMKIN in ANSYS 18.2:

Defines the Troe pressure-dependent reaction rate (see Equation 3-31 of the ANSYS Chemkin-Pro Theory Manual). 

TROE must be followed by the slash-delimited 3 or 4 parameters α, T***, T*, and T**; 

the fourth parameter is optional and if omitted, the last term in Equation 3-31 is not used.

@speth
Copy link
Member

speth commented Nov 9, 2019

I realized while looking at the warning added in #741 regarding this issue that there is an additional consideration of how this is handled by ck2cti and ck2yaml. ck2yaml silently drop the T2 parameter if a value of 0 is specified, the same as if it was not specified, while ck2cti preserves the zero.

So, in addition to warning about T** being specified as 0 at the time a Troe object is being instantiated (from whatever data source), we should probably also (a) warn about it in the converter scripts and (b) preserve the value as specified by the user.

@ischoegl
Copy link
Member

ischoegl commented Nov 10, 2019

This is an excellent point, and probably a philosophical question about ck2yaml: should the output be changed to pre-empt undesirable behavior or should it generate a literal conversion even if there are issues that will result in warnings? The discontinuities in the NASA polynomials raise a similar issue.

My own preference would be a literal translation. As long as ck2yaml preserves the zero, #741 would be a legitimate fix.

Edit ... I changed the ck2yaml behavior so a zero T2 value is preserved in #741

@bryanwweber
Copy link
Member

I agree that a literal translation is the best approach. To the extent that the warnings generated by Cantera prompt people to improve their mechanisms, I'm happy to be the nagging voice for people 😁

bryanwweber added a commit to bryanwweber/cantera that referenced this issue Nov 14, 2019
As demonstrated in Cantera#683, sometimes the zero values are intentional and
meaningful. Rework the SpeciesTransport class to not use this function.
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Nov 25, 2019
As demonstrated in Cantera#683, sometimes the zero values are intentional and
meaningful. Rework the SpeciesTransport class to not use this function.
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Nov 26, 2019
As demonstrated in Cantera#683, sometimes the zero values are intentional and
meaningful. Rework the SpeciesTransport class to not use this function.
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Nov 26, 2019
As demonstrated in Cantera#683, sometimes the zero values are intentional and
meaningful. Rework the SpeciesTransport class to not use this function.
bryanwweber added a commit to bryanwweber/cantera that referenced this issue Dec 2, 2019
As demonstrated in Cantera#683, sometimes the zero values are intentional and
meaningful. Rework the SpeciesTransport class to not use this function.
decaluwe pushed a commit to gkogekar/cantera that referenced this issue Dec 20, 2019
As demonstrated in Cantera#683, sometimes the zero values are intentional and
meaningful. Rework the SpeciesTransport class to not use this function.
srikanthallu pushed a commit to srikanthallu/cantera that referenced this issue Sep 17, 2020
As demonstrated in Cantera#683, sometimes the zero values are intentional and
meaningful. Rework the SpeciesTransport class to not use this function.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants