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
Preconditioned solver improvements #1377
Conversation
Using right preconditioning provides a more reliable performance benefit even after the ignition event, allowing the solver to take reasonable timesteps and showing a CPU-time benefit even for a single reactor with the 100-species n-dodecane mechanism.
Finite differences were being calculated incorrectly due to the arguments to the eval function being misinterpreted.
This is a useful reference for checking analytic or approximate Jacobian formulations, even if it isn't a particularly good Jacobian to use for integration generally.
Make exclusion of terms that cause Jacobian to be dense explicit rather than accidental. Include full derivatives of species equation in the derivatives of the energy equation, since this does not affect sparsity.
Codecov Report
@@ Coverage Diff @@
## main #1377 +/- ##
==========================================
+ Coverage 70.89% 70.95% +0.05%
==========================================
Files 357 357
Lines 51500 51532 +32
Branches 17198 17252 +54
==========================================
+ Hits 36510 36562 +52
+ Misses 12696 12664 -32
- Partials 2294 2306 +12
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Whoa. Great work @speth! |
Nice! |
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.
@speth ... I did not look into fine details, as this is something that @anthony-walker may be better prepared to do.
Apart from the minor tweak to make some getters consistent, I was wondering whether the semi-analytical m_kin->netProductionRates_ddT
could be leveraged in this context.
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.
@speth Nice work! I think a lot of the renaming and refactoring you have done makes sense.
@@ -9,6 +9,11 @@ | |||
namespace Cantera | |||
{ | |||
|
|||
AdaptivePreconditioner::AdaptivePreconditioner() | |||
{ | |||
setPreconditionerSide("right"); |
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.
It is interesting that "right"
preconditioning provides a better result. Does this apply to both constant pressure and constant volume cases?
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.
Yes, right preconditioning seems to generally be better for the constant volume case as well. I have no real insight as to why.
Yes, I think those derivatives could be used, but there are other terms, especially in the energy equation, that would have to be worked out first before you could avoid taking the temperature derivative as a finite difference based on |
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.
@speth … perfect, thanks!
Short version: This restores the performance of the preconditioned solver for reactor networks to what it was like before #1010 was rebased to resolve merge conflicts with the updated
Reactor
API from #1003.Changes proposed in this pull request
solverStats()
function (orsolver_stats
property in Python.Reactor::eval(double t, double* lhs, double* rhs)
method, treating it like the now-removedReactor::evalEqs(double t, double* y, double* ydot)
method. This resulted in wildly wrong values for these derivatives that caused poor performance for the preconditioned integrator.IdealGasMoleReactor::componentName
If applicable, provide an example illustrating new features this pull request is introducing
Results for a sample of ignition delay calculations before this PR:
Results for left preconditioning, using this PR:
Results for right preconditioning, using this PR:
And for reference, results using the standard dense integrator:
(and note that this last set is making use of the parallel BLAS/LAPACK implementation available through the macOS Accelerate framework, while the others are all purely single-threaded).
Checklist
scons build
&scons test
) and unit tests address code coverage