-
-
Notifications
You must be signed in to change notification settings - Fork 349
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
Incorporating the LMR-R mixture rule into Cantera for the first time #1710
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1710 +/- ##
==========================================
- Coverage 73.23% 73.10% -0.13%
==========================================
Files 381 383 +2
Lines 54378 54632 +254
Branches 9066 9106 +40
==========================================
+ Hits 39822 39937 +115
- Misses 11583 11694 +111
- Partials 2973 3001 +28 ☔ View full report in Codecov by Sentry. |
644fb9b
to
54cf13e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this contribution, @pjsingal! I have a couple of basic recommendations that mostly pertain to formatting. The example data should likely move to the new example_data
repository, but it is not urgent at the moment. You may also want to think about adding unit tests.
ee0a85f
to
780c996
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the continued work on this, @pjsingal. I would suggest that the first priority at this point is to add some unit tests. I would recommend getting those into place before making any of the other changes that I've suggested below, so you can be sure that making those changes doesn't introduce any regressions.
elif input_data: | ||
raise TypeError("Invalid parameter 'input_data'") | ||
else: | ||
raise TypeError("Invalid parameter 'rates'") | ||
self.set_cxx_object() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should be able to get the constructor from input_data
working by following the example of the other rate types. This is just a Python data structure containing the same information as the YAML input.
I think you can just remove the rates
kwarg -- I'm guessing that's just leftover from copying from the PlogRate implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I attempted to follow these instructions, and now have a very bare-bones version of it. However, I could use more advice re: what needs to be added now.
7f562c0
to
7ddab95
Compare
fa600b7
to
931a92a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates here, @pjsingal, I think we're getting fairly close.
Could you please temporarily remove the commit that updates the example_data
submodule? In that case, the jobs that build the docs and run the examples will fail, but at least all the others should run. Once we finalize the input file format and can merge the PR from the example_data repo, then we can update the submodule commit.
fd70c36
to
b8913c3
Compare
renamed eig0 to 'eps', representing 3-body collision eff and not ME eigenvalue
- Deleted unused constructor - 'collider-list'->'colliders', 'collider'->'name' - simplified loop logic in evalFromStruct - removed redundant validation step - added docstrings to all member vars - put check for A<0, emptied validate() - rm redundant getParameters() override - updated InputFileError statements and criteria - fixed issue with getParameters() defn - deleted eps_M in evalFromStruct
created linearBurke-test.yaml for unit tests
- added missing '<' to doxygen member var descrips - Protected member vars of rates class - added m_ prefix to protected mem vars - rm eps_mix from mem vars - protected submethods of evalfromstruct - fixed doxygen comms and citation in .h file - corrected to "linear-Burke" in .h file - colliders[0]["type"] = "falloff" (in .cpp file) - fixed "else if" formatting - simplified map insertion for m_colliderInfo - logPeff_ now local var passed as argument - fixed indent of if statement, rm "to_string" - user no longer needs to specify efficiency=1 for M - added "M" to colliderInfo in getParameters() - removed duck typing for troe/plog/chebyshev - put setRateIndex(0) in setParams for troe rate obj - added check if collider has type key - fixed check for collider type key - adjusted error msg for when 'M' lacks 'type' - repl "colliders_i" w/ "collider" in getParams
- getParams now casts type to colliderNode - 'efficiency' can be optionally added to 'M', but added check that it =1 in this case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all the updates, @pjsingal. I think this is good to go. I simplified the commit history and pushed one last commit that just adjusts some minor formatting issues in the code and docs.
Changes proposed in this pull request
LinearBurkeRate.cpp and LinearBurkeRate.h allow for vastly improved consideration of the mixture-dependent aspect of the rate constants for complex-forming ("pressure-dependent") reactions, using the new reduced-pressure linear mixture rule (LMR-R)
This code builds, runs, and produces results that have been validated and peer-reviewed
LMR-R can handle three different representations of the pressure-dependent aspect of complex-forming reactions: Troe, PLOG, and Chebyshev
LMR-R calculates the mixture-dependent aspect using temperature-dependent third-body efficiencies that have been supplied by the user for at least one collider - these parameters can be provided in either relative or absolute terms, as long as the user's choice is consistent for all colliders in a given reaction
Description of the theory and instructions for YAML implementation have been added to rate-constants.md and reactions.rst, respectively
Three new Python examples have been added: jet_stirred_reactor.py, shock_tube.py, flame_speed.py
The Python examples employ a mechanism containing linear-Burke reactions, ammonia-CO-H2-Alzueta-2023.yaml, which is being added to Cantera/cantera-example-data via a separate PR
Unit tests have been added, along with the linearBurke-test.yaml mechanism, stored in Cantera/Cantera/test/data
Checklist
[x] The pull request includes a clear description of this code change
[x] Commit messages have short titles and reference relevant issues
[x] Build passes (scons build & scons test) and unit tests address code coverage
[x] Style & formatting of contributed code follows contributing guidelines
[x] The pull request is ready for review