id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5287	Evaluation of propagated parameters with Evaluate = true	Francesco Casella	Per Östlund	"Please consider the following test case (that I suggest to add to the testsuite)
{{{
package P
  model M
    parameter Real tau;
    Real x;
  equation
    tau*der(x) + x = sin(time);
  end M; 
  model S
    parameter Real tau = 0 annotation(Evaluate = true);
    M m(tau = tau);
  end S;
  model S2
    parameter Real tau = 0 annotation(Evaluate = true);
    M m(final tau = tau);
  end S2;
end P;
}}}
The old front-end has a greedy tendency to evaluate stuff, so it evaluates both {{{tau}}} and {{{m.tau}}} in both {{{P.S}}} and {{{P.S2}}}, allowing the back-end to eliminate the product {{{tau*der(x)}}} and avoid the structural singularity.

The NF instead does not evaluate {{{m.tau}}} in either case, leading to a numerically singular model that cannot be solved.

In the case of {{{P.S2}}}, there is no question that the parameter {{{m.tau}}} should be evaluated to zero by the front-end, because the final modifier makes it identically equal to {{{tau}}}, which has the {{{Evaluate=true}}} annotation.

The case of {{{P.S}}} is a bit more controversial. In principle, since the modifier is not final, one may want to change the binding of {{{m.tau}}} to some other value at runtime, so the front-end may not evaluate it; however, this means that the {{{tau = 0}}} case would end up in a singular simulation model.

This issue affects for sure [https://libraries.openmodelica.org/branches/newInst/Modelica_trunk/files/Modelica_trunk_Modelica.Electrical.Analog.Examples.HeatingNPN_OrGate.sim Modelica.Electrical.Analog.Examples.HeatingNPN_OrGate] and [https://libraries.openmodelica.org/branches/newInst/Modelica_trunk/files/Modelica_trunk_Modelica.Electrical.Analog.Examples.HeatingPNP_NORGate.sim Modelica.Electrical.Analog.Examples.HeatingPNP_NORGate]. I opened [https://github.com/modelica/ModelicaStandardLibrary/pull/2812 PR #2812] on the MSL issue tracker, you can follow the discussion there.

No matter how that discussion will end, I suspect this pattern shows up in other places in the MSL and in other libraries, and causes lots of weird run-time errors on models that otherwise run fine if built with the OF.

I reckon that in all cases of use of the pattern shown in {{{P.S}}}, the intention of the modeller is that the propagated parameter {{{m.tau}}} also gets evaluated, even in the absence of a {{{final}}} qualifier. From an end-user perspective, expecting that the {{{Evaluate = true}}} property is somehow propagated feels quite natural, and, incidentally, that's WWDD.

So, I would also propose to add a heuristic rule that parameters who are bound to a parameter with the {{{Evaluate = true}}} annotation are marked as structural and evaluated. I guess this would solve a number of runtime issue and increase the coverage of the NF significantly. We may later on relax this rule if there are use cases which are negatively affected, but I can't think of any at this time."	defect	closed	high	2.0.0	New Instantiation		fixed		Lennart Ochel