id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
3487	Size-dependent strategies for solving systems of equations in OMC	Francesco Casella	Patrick Täuber	"Some methods that are used in OMC to solve systems of equations may only make sense for a certain range of system sizes, but their complexity could prevent them to be usable for larger systems, or their overhead could make them inconvenient for smaller systems. This impacts both the optimization and the simulation flags.

For example, moderately sized sparse linear systems can be handled effectively by tearing, which has the advantage of moving most of the computational load to the code generation phase, which is just carried out once. However, for increasing system size the time taken by the tearing algorithm could become prohibitevely large, and the torn system might still end up being very sparse, so at some point it is better to avoid tearing, and use a sparse solver instead. The same probably applies to nonlinear systems as well. 

The break-even point might actually change depending on the end-user need: if the simulation is very long or repeated many times without recompiling, it makes sense to spend more time in the compilation phase; the opposite while one is trying to debug a model with a short compile-run-modify cycle.

Currently, it is only possible to specify which method to use on a system-wide basis, but if a model contains both small and large systems, it is not possible to handle this situation appropriately.

It should then be possible to specify the range of sizes where the optimization should be applied, e.g.
{{{--disableLinearTearing>1000}}} or {{{--dynamicTearing>3<50}}}.

For the simulation option, the {{{-ls}}} and {{{-nls}}} options allow to select one linear and one nonlinear solver globally, which is not flexible enough. It should instead be possible to have multiple selections depending on the system size, and possibly also on other features of the system (e.g. sparsity ratio, availability of analytical Jacobian, etc.). I'm not sure what is the best syntax here to allow for maximum generality and flexibility without getting too complicated.

The ultimate goal is to select good default values for all these flags, so that the compiler automatically select the best solution strategy for the specific problem, without the need of input from the end user."	enhancement	closed	high		Backend		fixed		Adrian Pop