-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1710 +/- ##
==========================================
- Coverage 73.23% 72.87% -0.37%
==========================================
Files 381 383 +2
Lines 54375 54616 +241
Branches 9251 9282 +31
==========================================
- Hits 39823 39802 -21
- Misses 11580 11832 +252
- Partials 2972 2982 +10 ☔ View full report in Codecov by Sentry. |
5b74b9f
to
59d89de
Compare
…'t yet run (the version in previous commit both builds and runs)
…l speed by changing obj defs
ee0a85f
to
780c996
Compare
This reverts commit d355c9e.
…MRR ref materials
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.
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.
This mechanism is a good candidate for moving to the separate example_data
repository (https://github.com/Cantera/cantera-example-data).
I appreciate the effort to at least share the species data between the two versions of the mechanism, but I'd like to suggest going a step further, and sharing the reactions that they have in common as well. To do this, you would need to divide the reactions into three sections in the input file: one for the shared reactions (named for example common
), one for the baseline mechanism's pressure-dependent reactions (named for example baseline-pdep
), and one for the reactions implemented using the linear-Burke
rate model (named linear-Burke
). Then, you can put two phase definitions in the file, one which specifies the reactions as reactions: [common, baseline-pdep]
and the other that specifies the reactions as reactions: [common, linear-Burke]
.
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.
There are several other examples showing IDT as a function of temperature, so I think we probably don't need this example. Your paper is the main place for demonstrating this result.
Two models are compared in this example: | ||
(i) A 2023 model of H2 and NH3 chemistry published by Alzueta et al. [2] | ||
(ii) An adapted version of this model that has applied the reduced-pressure linear mixture | ||
rule (LMR-R) and ab initio third-body efficiencies [3] | ||
|
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.
Please make sure that this header can be parsed as reStructuredText and that the output looks like what you are expecting. You can take a look at the generated HTML by downloading the "docs" artifact from the CI builds (go to the "Checks" tab at the top of this PR page, then look through the list of "artifacts").
Also, please wrap content, including the comments, to no more than 88 characters.
@@ -0,0 +1,140 @@ | |||
//! @file LINEARBURKERATE.h |
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.
The capitalization here should match the capitalization of the file name -- otherwise, Doxygen issues a warning.
* The data container `LmrData` holds precalculated data common to | ||
* all `LinearBurkeRate` objects. | ||
*/ | ||
struct LmrData : public ReactionData |
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.
The name of this class should also be changed to something less obscure -- LinearBurkeData
would be consistent with the pattern that we use with the other rates and their corresponding data classes.
// Collider has an eps specified, but no other info is provided. Assign it the same rate and data objects as "M" | ||
else { | ||
rateObjs.push_back(rateObj_M); | ||
dataObjs.push_back(dataObj_M); | ||
epsObjs1.push_back(epsObj_i); | ||
epsObjs2.push_back(epsObj_M); | ||
} | ||
} |
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.
Since this seems to be the most common case (based on the mechanism used in the examples), for the sake of efficiency I think you want to avoid recalculating the value of rateObj_M
for each collider when (I think) it will just have the same value for all of them and all you really need is to compute it once and scale it by the sum of the efficiency-weighted mole fractions.
mixture rule | ||
multicomponent transport |
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 don't think this is going to be a well-understood keyword to most users, and I'd recommend just leaving it out.
species profile | ||
temperature profile |
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 would recommend dropping these two keywords as well
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.
void getParameters(AnyMap& rateNode, const Units& rate_units) const; | ||
void getParameters(AnyMap& rateNode) const override { | ||
return getParameters(rateNode, Units(0)); | ||
} |
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 think you can just implement the version that doesn't take a Units
object directly and skip providing this other overload of getParameters
.
Changes proposed in this pull request
LmrRate.cpp and LmrRate.h allow for vastly improved consideration of the mixture-dependent aspect of the rate constants for complex-forming ("pressure-dependent") reactions, using the new LMR-R mixture theory developed by the Burke Lab at Columbia University
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 implementation have been added to rate-constants.md and reactions.rst, respectively
Four new Python examples have been added
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