id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5458	Unknowns with explicitly set start attributes should be preferred as tearing variables	Francesco Casella	Lennart Ochel	"Consider the model [https://libraries.openmodelica.org/branches/newInst/Modelica_3.2.3/files/Modelica_3.2.3_Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator.err Modelica.Electrical.Analog.Examples.OpAmps.SignalGenerator]. 

The component {{{opAmp1}}} has a positive feedback connection, with two possible initial equilibrium points: one with {{{v_out = -15}}}, the other one with {{{v_out = 0}}}. This is the result of the solution of a strongly nonlinear system of equations. The following declaration in the model
{{{
  Modelica.Electrical.Analog.Basic.Resistor r2(R=R2, i(start=Vps/R2))
}}}
leads to the convergence to the desired initial condition (i.e., {{{v_out = -15}}}), which starts a cycle of oscillations, as in the reference solution, as long as {{{r2.i}}} is selected as iteration/tearing variable. Unfortunately, OMC selects a different unknown as tearing variable, which has the default start value of zero; as a consequence, the wrong solution is selected, and no oscillations ensue.

One solution to this issue is to add appropriate start values to all potential iteration variables in the MSL source code, in order to guarantee that the correct solution is found irrespective of the selected iteration variables. However, this is a bit cumbersome.

It would be nicer if the tearing algorithm could give higher priority to r2.i in the selection as tearing variable candidate, since its start value is explicitly modified in the model, while the other potential tearing variables only have the default set by their type. 

This feature would make OMC more robust in handling models that were developed with other tools (as in this case), whereby some start values are set in order to steer the convergence of the solver towards the desired solution.

Karim, Andreas, Lennart, do you think this could be implemented without too much effort?"	defect	closed	blocker	1.14.0	Backend		fixed		Andreas Heuermann Lennart Ochel Karim Adbdelhak