Opened 3 years ago

Closed 3 years ago

#5284 closed defect (fixed)

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

Reported by: casella Owned by: perost
Priority: high Milestone: 2.0.0
Component: New Instantiation Version:
Keywords: Cc:


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:
assert            | info    | simulation terminated by an assertion at initialization

The value of, which is a variable, is computed by the equation

cc = Modelica.Electrical.Spice3.Internal.Jfet.jfetNoBypassCode(

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*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*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?

Change History (1)

comment:1 Changed 3 years ago by casella

  • Resolution set to fixed
  • Status changed from new to closed

Fixed by e11c6c60

Note: See TracTickets for help on using tickets.