Partial Function Evaluation in Backend for Spice3

[Christian Schubert]

Volker and I had a look at the Inverter Model and found out why it cannot be simulated by omc.
Let me try to explain the problem. Inside the M_NMOS component we have the equations

   icBD = cc.cBD * (der(B.v) - der(Dinternal));
   icBS = cc.cBS * (der(B.v) - der(Sinternal));
   icGB = cc.cGB * (der(G.v) - der(B.v));
   icGD = cc.cGD * (der(G.v) - der(Dinternal));
   icGS = cc.cGS * (der(G.v) - der(Sinternal));

which is the only occurance of der(Dinternal) (and the other der() variables).
Unfortunately cc.cBD (and in fact all cc.c*) evaluate to constant zero and thus the equations cannot be solved for der(Dinternal), for example.
During compile time however, OpenModelica doesn't notice that cc.c* is zero and therefore cannot take any measures against it.

This is because cc is solved in the equation

  cc = Mos.mosCalcNoBypassCode(
    m,
    m_type,
    c2,
    p,
    C,
    vp,
    m_bInit,
    {G.v, B.v, Dinternal, Sinternal});

most function parameters are evaluated to be constants by the Backend, however (due to constants, final parameters and Evalute=true annotations)
bltdump tells us

mp.cc = Modelica.Electrical.Spice3.Internal.Mos.mosCalcNoBypassCode(
Modelica.Electrical.Spice3.Internal.Mosfet.Mosfet(300.15, 0.0001, 0.0001, 0.0, 0.0, 1.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0, 1, 1, 0.0, 0.0, false), 
-1, 
Modelica.Electrical.Spice3.Internal.Mos1.Mos1Calc(0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.00002, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1, 0.0001, 0.0, 0.0, 0.00002, 600.0, 0.6, 0.0, 0.0, 0.00000000000001, 0.00000000000001, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.8, 0.4, 0.0, 0.7302833841653967, 0.7302833841653967, 0.4686291501015239, 0.3535533905932738, 0.25, 0.0, 0.0, 0.0, 0.025864709055120616, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0), 
Modelica.Electrical.Spice3.Internal.Mos1.Mos1ModelLineParams(0.0, 0.0, 0.8, 0.5, 0.5, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 1.0, 0.0, 1.0, 0.0, 0.5, 0.6, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 600.0, 0.0, 0.00000000000001, 0.0, 1.0, 0.0, 1.0, 0.00002, 0.0, 300.15), 
Modelica.Electrical.Spice3.Internal.SpiceConstants(0.00000000010359431399069999, 0.00000000003453133, 0.00000000000000000016021918, 273.15, 0.000000000000000000000013806226, 300.15, 1.4142135623730951, 2.718281828459045, 0.000000000001, 300.15, 300.15, 0.0, 0.0, 0.0001, 0.0001, 0.0000000001, 0.000000000000001, 0.0000000001, 0.001, 0.025864709055120616, 0.0000861726105451295), 
Modelica.Electrical.Spice3.Internal.Mos.MosModelLineVariables(0.0, 0.0, 0.6, 0.0, 0.00002), 
false, 
{mn.G.v, mp.B.v, mp.B.v, mn.Dinternal})

Since, there are still time-varying parameters left, namely {mn.G.v, mp.B.v, mp.B.v, mn.Dinternal}, the function is not being evaluated.

However, by looking at the code of Mos.mosCalcNoBypassCode one finds that

  out_cc.cBD := if (in_m_bInit) then 1e-15 else (int_c.m_capbdb + int_c.m_capbds);

where the following constants are known

in_m_bInit = false;
int_c.m_capbdb = 0;
int_c.m_capbds = 0;

And thus out_cc.cBD is also known. If those information were available to the backend, it should be possible to simulate models from the Spice3 library.

Thus, in my opinion we need a new backend module which "partly evaluates" functions. What I mean is, that we take a function

{cc.a, cc.b} = f_original(constant, variable)

"copy it" and create a new function

{cc.a} = f_new(variable)

which only depends on the non-constant parameters and where the constants are evaluated inside the function possibly assigning already known outputs (In this example cc.b).

Volker knows well how to write such a backend module. However, it would be nice if he would get some advice on how to copy and evaluate such a function efficiently.

[Martin Sjölund]

Start with creating a mapping of which input variable(s) are required to calculate each output variable, including individual components in records? I suspect there are a lot of candidate functions for such an optimisation, so you need this mapping to answer quickly if this function could be transformed.

[Volker Waurich]

the current problem is: ticket:2624

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.