NFTyping.typeComponents fails on many MSL models because of missing function evaluation

[Francesco Casella]

Modelica.Blocks.Examples.PID_Controller
Modelica.Blocks.Examples.Filter
Modelica.Blocks.Examples.FilterWithDifferentiation
Modelica.Blocks.Examples.FilterWithRiseTime
and many others fail after reporting "Performance of NFInst.instExpressions", see e.g.

​https://dev.openmodelica.org/libraries/MSL_3.2.2/files/Modelica.Blocks.Examples.PID_Controller.err

BTW, it is not clear if NFInst.instExpressions was successfully completed and the error is reported during the execution of the next function, e.g. NFInst.instExpression, or if the notification of NFInst.instExpression is issued anyway even if an error happened inside it.

Please clarify for future reference.

The error message is:

Error: Internal error Instantiation of <ModelName> failed with no error message.

[Per Östlund]

BTW, it is not clear if NFInst.instExpressions was successfully completed and the error is reported during the execution of the next function, e.g. NFInst.instExpression, or if the notification of NFInst.instExpression is issued anyway even if an error happened inside it.

Performance info is only given for completed phases, i.e. NFInst.instExpressions completed successfully in this case.

[Per Östlund]

It seems like the error logs from Hudson doesn't capture asserts. Instantiating PID_Controller myself gives:

[NFSimplifyExp.mo:176:9-176:105:writable]Modelica Assert: Unimplemented case for max({{1}, {1}, {1}}) in NFSimplifyExp.postSimplify!

The Filter models instead gives:

NFSimplifyExp.mo:176:9-176:105:writable]Modelica Assert: Unimplemented case for mod(3, 2) in NFSimplifyExp.postSimplify!

As the line numbers indicate this is actually the same assert, for missing handling of function calls. We haven't implemented any evaluation of functions yet, builtin or otherwise, and these expressions are used as dimensions and thus needs to be evaluated.

[Francesco Casella]

Replying to perost:

It seems like the error logs from Hudson doesn't capture asserts.

Another case of Hudson fake news? ;)

There is a very large number of models in the MSL 3.2.2 that fails to flatten and for which the Hudson log does not report any error message. Please fix this ASAP, so we can more clearly identify what the problems are. Running models locally on one's own PC is not a feasible option for large-scale screening.

[Francesco Casella]

Replying to perost:

As the line numbers indicate this is actually the same assert, for missing handling of function calls. We haven't implemented any evaluation of functions yet, builtin or otherwise, and these expressions are used as dimensions and thus needs to be evaluated.

I'm still unsure how many models fail for this, but I guess it could be many.

From #4138 I read

Function Evaluation (Lennart) 1%
Sometimes to evaluate structural parameters one needs to evaluate functions. This will port the function interpretation from the current front-end to the new front-end.

Maybe it's just about time to start implementing this feature as well. @lochel, how long would that take and when could you take care of that?

[Per Östlund]

Replying to casella:

Replying to perost:
From #4138 I read

Function Evaluation (Lennart) 1%
Sometimes to evaluate structural parameters one needs to evaluate functions. This will port the function interpretation from the current front-end to the new front-end.

Maybe it's just about time to start implementing this feature as well. @lochel, how long would that take and when could you take care of that?

That particular feature refers to function interpretation of general functions, but builtin functions like max or mod should just be handled as special cases in NFSimplifyExp.

[Martin Sjölund]

Replying to perost:

It seems like the error logs from Hudson doesn't capture asserts.

That's because assert() is a Modelica built-in and not part of Error.mo. Only messages printed to the error buffer is captured by the script (OMPython does not really expose messages printed to stdout). Use Error.assertion(cond, message, sourceInfo()) instead of assert(cond, message). (Should we make the bootstrapping generate warnings for this?)

[Francesco Casella]

Replying to sjoelund.se:

Replying to perost:

It seems like the error logs from Hudson doesn't capture asserts.

That's because assert() is a Modelica built-in and not part of Error.mo. Only messages printed to the error buffer is captured by the script (OMPython does not really expose messages printed to stdout). Use Error.assertion(cond, message, sourceInfo()) instead of assert(cond, message). (Should we make the bootstrapping generate warnings for this?)

I just opened #4676 on this specific issue.

[Francesco Casella]

All the reported example now issue meaningful error messages. I'll re-open a specific ticket on those errors