id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5284	Issue caused by moving record binding equations to the initial equation section in the NF	Francesco Casella	Per Östlund	"Please check [https://libraries.openmodelica.org/branches/newInst/Modelica_trunk/files/Modelica_trunk_Modelica.Electrical.Spice3.Examples.CascodeCircuit.sim Modelica.Electrical.Spice3.Examples.CascodeCircuit]. The runtime fails with
{{{
assert            | debug   | division leads to inf or nan at time 0, (a=-0) / (b=-nan), where divisor b is: J2.cc.cGS
assert            | info    | simulation terminated by an assertion at initialization
}}}
The value of {{{J2.cc.cGS}}}, which is a variable, is computed by the equation
{{{
cc = Modelica.Electrical.Spice3.Internal.Jfet.jfetNoBypassCode(
    m1,
    p2,
    m_type,
    m_bInit,
    {G.v,Dinternal,Sinternal});
}}}
When the OF is used, the backend is able to determine that the {{{cGS}}} component of the vector output of this function call is constant and equal to zero; hence, it can remove the product {{{J2.cc.cGS*der(J2.vGS)}}} symbolically from the equations.

Unfortunately, this does not happen when the NF is used, so that eventually the runtime fails because of division by zero when it tries to compute {{{der(J2.vGS)}}}.

The {{{jfetNoBypassCode}}} is flattened exactly in the same way by the OF and by the NF. However, if one looks at the inputs of the function, the OF-flattened model contains
{{{
final parameter Real J2.p2.m_capGS(
  quantity = ""Capacitance"", unit = ""F"", min = 0.0, start = 0.0) = 0.0 ""CGS"";
}}}
which has a binding to zero, allowing the back-end to determine that the {{{cGS}}} field of the function output record is a constant zero. The NF-flattened model instead contains the following code
{{{
  final parameter Real J2.p2.m_capGS(
    quantity = ""Capacitance"", unit = ""F"", min = 0.0, start = 0.0, fixed = false) ""CGS"";
...
initial equation
  J1.p2 = Modelica.Electrical.Spice3.Internal.Jfet.jfetModelLineInitEquations(J1.p1);
}}}

It seems that in this case (and in many other similar cases in {{{Modelica.Electrical}}} that fail for the same reason), the strategy of replacing a record binding equation for parameter {{{J1.p2}}} with the corresponding initial equation has an adverse effect, because it prevents the NF to evaluate the function in the binding equation and actually find out that J1.p2.m_capGS = 0.0. 

Since the back-end doesn't even try to figure out this piece of information from the initial equations, it loses the chance of symbolically removing  {{{J2.cc.cGS*der(J2.vGS)}}}, and therefore ends up with a singular system that cannot be simulated.

Is there any chance that the NF can try to evaluate these record binding equations, before moving them to the initial equation section?
"	defect	closed	high	2.0.0	New Instantiation		fixed