﻿id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
2576	Partial Function Evaluation in Backend for Spice3	Christian Schubert	probably noone	"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."	defect	new	high	Future	Backend	trunk		Spice3 function evaluation partial	Adrian Pop Martin Sjölund Willi Braun Lennart Ochel Volker Waurich Jens Frenkel
