-
-
Notifications
You must be signed in to change notification settings - Fork 353
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
Make reactions extendable #982
Conversation
d4edc62
to
fe57129
Compare
Codecov Report
@@ Coverage Diff @@
## main #982 +/- ##
==========================================
- Coverage 71.56% 70.67% -0.90%
==========================================
Files 359 362 +3
Lines 45666 44555 -1111
==========================================
- Hits 32683 31489 -1194
- Misses 12983 13066 +83
Continue to review full report at Codecov.
|
- replace 'wrapReaction' by 'Reaction.wrap' method - eliminate hard-coded object instantiation
- deprecate magic numbers
- relocation to ReactionFactory removes function from interface
9b5f0ba
to
8918c36
Compare
kicking this back to draft - I am planning to extend the framework by a custom Python class to work out some of the issues mentioned in Cantera/enhancements#63 (there are some bits in |
* streamline names: - RxnRate -> ReactionRate - CustomPyRate -> CustomFunc1Rate - CustomPyReaction -> CustomFunc1Reaction * label some (potentially temporary) methods as @internal * minor fixes in Python interface
After removal of XML support, some service functions can be removed to simplify the code structure.
The member 'setup' method avoids having to recreate separate stand-alone setup methods.
The intermediate class prevents naming clashes between derived classes (e.g. 'rate' members).
fcb5a58
to
b3194f6
Compare
Force-pushed as I found a better solution to allow for PS: As of this morning, it looks like boost is - at least partially - broken (#990) PPS: Overall, I'd propose to limit the current PR to the creation of the |
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, @ischoegl, I think this is getting very close. Most of my comments below are fairly minor implementation details. I have no problem leaving the follow-on work you've mentioned to later PRs. The only thing I'm not looking forward to is fixing the merge conflicts this will introduce to #984 😬.
One thing I'm still a little iffy on is all the constructors that have to be implemented for each DataType
class in order to support evaluation of rates for reactions not associated with any Kinetics
object. While I recognize that T and P are sufficient for quite a few cases, what are you supposed to do for the cases where that doesn't work? Having to implement all of those constructors and throw an exception in them seems kind of tedious, and I don't think we should require users to do that. Would it make sense to have a common base class for the DataType
classes, with update_T
and update_TP
methods that throw NotImplementedError
by default?
@speth ... done. I actually looked at #984 and there are surprisingly few (and simple) merge conflicts. I ended up renaming I also looked into your comment on Regarding next steps, I may wait for #984 to be merged, as there are some synergies. Once that is done, I am planning to create new classes mirroring the old ones (e.g. |
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 quick revisions. This all looks good to me.
I think these changes to the ReactionData
interface will work fine, at least for the time being. I imagine that as we exercise this capability on the existing rate classes, we'll be able to get a better feel for possible improvements / simplifications.
Changes proposed in this pull request
ReactionFactory
in C++ReactionRateBase
allows for flexible implementations (derived classes are de-virtualized)MultiRateBase
class is introduced as an alternative toRate1
templatesCustomReaction
in Python usesFunc1
objectsApproach
The main philosophy is to replace hard-coded reaction instantiation by an extendable
ReactionFactory
approach. None of this affects calculated outcomes. I.e. this PR repackages what's already there, with the difference that it becomes very simple to add additional reaction types.Example:
GasKinetics
becomes fully flexible, i.e. someone can define a new reaction type externally and link it against cantera (ctwrap
approach, where new C++ lambda functions are registered for an existing cantera factory object).Implementation
If applicable, fill in the issue number this pull request is fixing
Supersedes #745 (can no longer be opened as it was rebased)
Fixes Cantera/enhancements#63 (a new framework is introduced, but not fully implementated)
A full replacement of
Rate1
goes beyond the scope of this PR.References:
Checklist
scons build
&scons test
) and unit tests address code coverage