Opened 4 years ago
Last modified 3 years ago
#6377 assigned defect
Avoid generating dense Jacobian above a certain size and set default solvers accordingly
| Reported by: | Francesco Casella | Owned by: | Karim Adbdelhak |
|---|---|---|---|
| Priority: | blocker | Milestone: | 1.19.0 |
| Component: | *unknown* | Version: | 1.18.0-dev |
| Keywords: | Cc: | Andreas Heuermann, Philip Hannebohm, Martin Sjölund |
Description
From what I can understand, the choice between using dense and sparse solvers is deferred to the runtime, since simulation flags such as -s, -idaLS, -nls, -nlsLS etc. allow to pick which one is used after the code has been compiled. This is relevant in several contexts where Jacobians are needed:
- initial equations
- lambda0-initial equations
- algebraic loops in
odeMode - symbolic Jacobians for stiff ODE solvers
- DAE Jacobians in
daeMode
I guess setting -daeMode avoids the generation and use of dense Jacobians for the direct DAE solution, which is really only possible with sparse solvers. @Karim, @AnHeuermann, could you please confirm that?
Anyway, I guess we should also skip building, analyzing, and generating code for dense jacobians in all other contexts, as soon as their size/density exceeds a certain threshold, which should be defined by compiler flags, and later read and used as default by the runtime.
For sure it makes no sense to waste time and memory handling dense matrices with more than a few hundred lines and columns, if they are sparse and sparse solvers are available.
See also #6342 for a discussion on the criteria.
Doing this should automatically ensure that reasonable choices are taken by default in terms of whether or not generating code for sparse/dense solvers, and in terms of automatic choice of the right solver given the structure and size of the problem.
Change History (5)
comment:1 by , 4 years ago
| Cc: | added |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:2 by , 4 years ago
comment:3 by , 4 years ago
Apparently no major changes in performance after PR 7164, see report.
I guess at the end of the day we never actually multiply dense matrices so big to spill over the cache limits, unless a really bad choice of dense vs. sparse is made.
The problem remains that this choice should be performed automatically.
@phannebohm addressed the traversal order in PR 7164.
A good test case is the ScalableTestGrids library. The latest test report is found here. We can check what happens when your PR is merged in and the test run again. You can also check the regression reports, if there is a dramatic improvement in performance, it should get reported.