Issue caused by moving record binding equations to the initial equation section in the NF

[Francesco Casella]

Please check ​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?

[Francesco Casella]

Fixed by e11c6c60