Lots of equations coming out of nowhere in the NF

[Francesco Casella]

Please consider the model ​Modelica.Electrical.Spice3.Examples.CascodeCircuit. After "Trasformations before backend" the NF reports:

Error: Too many equations, over-determined system. The model has 298 equation(s) and 68 variable(s).

I flattened the model in OMEdit and the result definitely has around 70 equations, not around 300:

  J2.D.v = J1.S.v;
  UDD.n.v = ground.p.v;
  UDD.n.v = U0.n.v;
  UDD.n.v = v_sin.n.v;
  UDD.n.v = J2.S.v;
  v_sin.p.v = J2.G.v;
  U0.p.v = J1.G.v;
  J1.D.v = RC.p.v;
  UDD.p.v = RC.n.v;
  RC.p.i + J1.D.i = 0.0;
  J2.D.i + J1.S.i = 0.0;
  v_sin.n.i + U0.n.i + UDD.n.i + ground.p.i + J2.S.i = 0.0;
  UDD.p.i + RC.n.i = 0.0;
  U0.p.i + J1.G.i = 0.0;
  v_sin.p.i + J2.G.i = 0.0;
  J1.p = Modelica.Electrical.Spice3.Internal.Jfet.jfetRenameParameters(J1.modelcard);
  J1.m = Modelica.Electrical.Spice3.Internal.Fet.fetRenameParametersDev(J1.AREA, J1.OFF, J1.IC_VDS, J1.IC_VGS, J1.UIC, J1.TEMP);
  J1.p1 = Modelica.Electrical.Spice3.Internal.Jfet.jfetInitEquations(J1.m, J1.p);
  J1.p2 = Modelica.Electrical.Spice3.Internal.Jfet.jfetModelLineInitEquations(J1.p1);
  J1.m1 = Modelica.Electrical.Spice3.Internal.Jfet.jfetCalcTempDependencies(J1.m, J1.p2);
  J1.cc = Modelica.Electrical.Spice3.Internal.Jfet.jfetNoBypassCode(J1.m1, J1.p2, J1.m_type, false, {J1.G.v, J1.Dinternal, J1.Sinternal});
  J1.vGD = J1.G.v - J1.Dinternal;
  J1.vGS = J1.G.v - J1.Sinternal;
  J1.ird * J1.p2.m_drainResist = J1.D.v - J1.Dinternal;
  J1.irs * J1.p2.m_sourceResist = J1.S.v - J1.Sinternal;
  J1.icGD = J1.cc.cGD * der(J1.vGD);
  J1.icGS = J1.cc.cGS * der(J1.vGS);
  J1.igsgmin = 1e-012 * (J1.G.v - J1.Sinternal);
  J1.igdgmin = 1e-012 * (J1.G.v - J1.Dinternal);
  J1.G.i = J1.icGD + J1.icGS + J1.cc.iGD + J1.igdgmin + J1.cc.iGS + J1.igsgmin;
  J1.D.i = J1.ird;
  J1.S.i = J1.irs;
  0.0 = (-J1.ird) + J1.cc.idrain - J1.cc.iGD - J1.igdgmin - J1.icGD;
  0.0 = (-J1.irs) - J1.cc.idrain - J1.cc.iGS - J1.igsgmin - J1.icGS;
  J2.p = Modelica.Electrical.Spice3.Internal.Jfet.jfetRenameParameters(J2.modelcard);
  J2.m = Modelica.Electrical.Spice3.Internal.Fet.fetRenameParametersDev(J2.AREA, J2.OFF, J2.IC_VDS, J2.IC_VGS, J2.UIC, J2.TEMP);
  J2.p1 = Modelica.Electrical.Spice3.Internal.Jfet.jfetInitEquations(J2.m, J2.p);
  J2.p2 = Modelica.Electrical.Spice3.Internal.Jfet.jfetModelLineInitEquations(J2.p1);
  J2.m1 = Modelica.Electrical.Spice3.Internal.Jfet.jfetCalcTempDependencies(J2.m, J2.p2);
  J2.cc = Modelica.Electrical.Spice3.Internal.Jfet.jfetNoBypassCode(J2.m1, J2.p2, J2.m_type, false, {J2.G.v, J2.Dinternal, J2.Sinternal});
  J2.vGD = J2.G.v - J2.Dinternal;
  J2.vGS = J2.G.v - J2.Sinternal;
  J2.ird * J2.p2.m_drainResist = J2.D.v - J2.Dinternal;
  J2.irs * J2.p2.m_sourceResist = J2.S.v - J2.Sinternal;
  J2.icGD = J2.cc.cGD * der(J2.vGD);
  J2.icGS = J2.cc.cGS * der(J2.vGS);
  J2.igsgmin = 1e-012 * (J2.G.v - J2.Sinternal);
  J2.igdgmin = 1e-012 * (J2.G.v - J2.Dinternal);
  J2.G.i = J2.icGD + J2.icGS + J2.cc.iGD + J2.igdgmin + J2.cc.iGS + J2.igsgmin;
  J2.D.i = J2.ird;
  J2.S.i = J2.irs;
  0.0 = (-J2.ird) + J2.cc.idrain - J2.cc.iGD - J2.igdgmin - J2.icGD;
  0.0 = (-J2.irs) - J2.cc.idrain - J2.cc.iGS - J2.igsgmin - J2.icGS;
  RC.R * RC.i = RC.v;
  RC.v = RC.p.v - RC.n.v;
  0.0 = RC.p.i + RC.n.i;
  RC.i = RC.p.i;
  ground.p.v = 0.0;
  UDD.v = UDD.V;
  UDD.v = UDD.p.v - UDD.n.v;
  0.0 = UDD.p.i + UDD.n.i;
  UDD.i = UDD.p.i;
  U0.v = U0.V;
  U0.v = U0.p.v - U0.n.v;
  0.0 = U0.p.i + U0.n.i;
  U0.i = U0.p.i;
  assert(v_sin.FREQ > 0.0, "Frequency less or equal zero");
  v_sin.v = v_sin.VO + (if time < v_sin.TD then 0.0 else v_sin.VA * exp(-(time - v_sin.TD) * v_sin.THETA) * sin(2.0 * 3.141592653589793 * v_sin.FREQ * (time - v_sin.TD)));
  v_sin.v = v_sin.p.v - v_sin.n.v;
  0.0 = v_sin.p.i + v_sin.n.i;
  v_sin.i = v_sin.p.i;

I really wonder where the additional 230 equations come from. Any clue?

[Martin Sjölund]

Could it be conditional connections that have not been removed?

[Francesco Casella]

As far as I understand the Spice3 library does not use conditional connectors at all

[Per Östlund]

Yes, the model has no conditional connectors. I suspect the issue is that with the new frontend there are a number of function calls that aren't evaluated that return big records. They're probably somehow marked wrong in the DAE so that the individual record fields are counted, or the equation counting is wrong somehow.

So the issue with this particular model might be solved once we get function evaluation, but the root cause still needs to be investigated since not all function calls can be evaluated (e.g. non-constant calls).

[Martin Sjölund]

Old FE has:

final parameter Real J1.m1.m_dTemp(quantity = "ThermodynamicTemperature", unit = \"K\", displayUnit = "degC", min = 0.0, start = 300.15, nominal = 300.0) = 300.15 "TEMP, Device Temperature";

New FE has:

final parameter Real J1.m1.m_dTemp(quantity = "ThermodynamicTemperature", unit = "K", displayUnit = "degC", min = 0.0, start = 300.15, nominal = 300.0) "TEMP, Device Temperature";

It instead has (in the continuous-time section; not initial equation):

J1.m1 = Modelica.Electrical.Spice3.Internal.Jfet.jfetCalcTempDependencies(J1.m, J1.p2);

[Francesco Casella]

Sounds to me very similar to what is discussed in ticket:4872#comment:1

[Per Östlund]

Replying to casella:

Sounds to me very similar to what is discussed in ticket:4872#comment:1

I had a closer look, and that is exactly the issue. The extra equations comes from parameter record bindings that couldn't be evaluated and were moved to the equation section so as not to loose them.

So once we implement function evaluation this should be fixed, with the added requirement that complex parameter bindings should always be evaluated regardless of whether the parameter is structural or not (since the new frontend normally only evaluates bindings of structural parameters).

I tried your idea of moving the bindings to the initial equation section instead, since that was trivial to do, and that does make the model balanced. But then the backend fails in removeSimpleEquations for an unknown reason instead. Maybe making the parameters fixed as you suggested would fix that, but as soon as we have function evaluation we won't be moving parameter bindings anyway.

[Francesco Casella]

Replying to perost:

I tried your idea of moving the bindings to the initial equation section instead, since that was trivial to do, and that does make the model balanced. But then the backend fails in removeSimpleEquations for an unknown reason instead. Maybe making the parameters fixed as you suggested would fix that, but as soon as we have function evaluation we won't be moving parameter bindings anyway.

OK, never mind that, please go ahead with function evaluation.

[Martin Sjölund]

We have had this problem in the old FE as well. You cannot always evaluate all bindings, so that will not really help in the general case. You need to move the equations to the initial section and mark the variables fixed=false (or modify the DAE to have some initial bindings section).

[anonymous]

Replying to sjoelund.se:

We have had this problem in the old FE as well. You cannot always evaluate all bindings, so that will not really help in the general case. You need to move the equations to the initial section and mark the variables fixed=false (or modify the DAE to have some initial bindings section).

Does the approach work if redeclare and replaceable are involved?

[Martin Sjölund]

Replying to anonymous:

Does the approach work if redeclare and replaceable are involved?

It should. As long as the modifications are handled before the typing (as in NF).

[Per Östlund]

I'm not sure which particular fix solved this issue, but it seems to have been fixed. The model simulates now but gets a division by zero during the simulation, so it seems something is still not quite right.