id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
6342	Make sure the sparse solver is used when appropriate	Francesco Casella	Francesco Casella	"Please check the attached test package. It contains a battery of scaled tests involving sparse initial equations systems of increasing size. There are on average about three variables in each equation, a degree of sparsity that is commonly found in object-oriented models. Tearing is deactivated, to inquire the behaviour of the naked numerical solver.

These are the reported times spent on initialization with increasing size, with the default option and with simulation flags {{{-nls=kinsol, -nlsLS=klu}}}
|| N || T default || T flags ||
|| 10 || 0.0004 || 0.00018 ||
|| 20 || 0.0015 || 0.00023 ||
|| 40 || 0.004  || 0.00028 ||
|| 80 || 0.047  || 0.00049 ||
|| 160 || 0.085 || 0.00076 ||
|| 320 || 0.52 || 0.0015 ||
|| 640 || 6.7 || 0.0028 ||

The default values for the automatic activation of the sparse nonlinear solver are {{{-nlssMinSize=10001}}} and {{{-nlssMaxDensity=0.2}}}. In all the cases reported in the second column, when the defaults are not changed, the used solver is the built-in dense Newton/homotopy solver.

It is very clearly visible as the solution times grows as O(N^3^) in the default case, because of the computational complexity of dense linear solvers. On the other hand, the time spent by the sparse solver grows as O(N). 

For this very sparse system (the density is about 3/N for large enough N) the sparse solver systematically outperforms the dense one. Until about 100 equations both are very fast anyway, but the time spent by the dense solver goes quickly through the roof as the size goes about that, making it very inefficient to solve systems above 300 equations. This is way below the current default limit.

We should probably try out sparse systems with higher density and sparsity patterns other than tri-diagonal, but I have no time to do that right now. My current experience with ScalableTestGrid systems, where initial equations mostly involve two or three variables each, confirm the findings on the attached simple test case.

I would then drastically reduce the default value of {{{-nlssMinSize}}}, and also of {{{-lssMinSize}}}, since the performance penalty of the nonlinear solver is entirely due to the poor performance of the linear solver employed by the Newton algorithm, so there is no reason to treat linear and nonlinear systems in different ways. 

Based on the results of this test, we could take a default value which is as low as 10. Recall that we also have a maximum limit of density {{{-nlssMaxDensity=0.2}}}, so systems of slightly higher size, say 20 or 30 equations, but also with density higher than 0.2, e.g. because of tearing, would still be handled by the dense solver, which would probably be the most appropriate in that case."	defect	closed	critical	1.19.0	Run-time	1.16.0	fixed		Andreas Heuermann Karim Adbdelhak jean-philippe.tavella@…