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! |
ischoegl
left a comment
ischoegl
left a comment
There was a problem hiding this comment.
@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.
anthony-walker
left a comment
anthony-walker
left a comment
There was a problem hiding this comment.
@speth Nice work! I think a lot of the renaming and refactoring you have done makes sense.
|
|
||
| AdaptivePreconditioner::AdaptivePreconditioner() | ||
| { | ||
| setPreconditionerSide("right"); |
There was a problem hiding this comment.
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.
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 |
4 participants
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
ReactorAPI from #1003.Changes proposed in this pull request
solverStats()function (orsolver_statsproperty 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::componentNameIf 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