#4660 closed defect (fixed)
NFTyping.typeComponents fails on many MSL models because of missing function evaluation
Reported by: | casella | Owned by: | perost |
---|---|---|---|
Priority: | high | Milestone: | 1.13.0 |
Component: | New Instantiation | Version: | |
Keywords: | Cc: | lochel |
Description (last modified by 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.
Change History (10)
comment:1 Changed 7 years ago by casella
- Description modified (diff)
- Summary changed from NFTyping.typeComponents fails on many MSL models to NFTyping.typeComponents (or NFInst.instExpressions?) fails on many MSL models
comment:2 Changed 7 years ago by perost
comment:3 follow-ups: ↓ 4 ↓ 5 ↓ 8 Changed 7 years ago by perost
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.
comment:4 in reply to: ↑ 3 Changed 7 years ago by 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.
comment:5 in reply to: ↑ 3 ; follow-up: ↓ 7 Changed 7 years ago by casella
- Cc lochel added
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?
comment:6 Changed 7 years ago by casella
- Summary changed from NFTyping.typeComponents (or NFInst.instExpressions?) fails on many MSL models to NFTyping.typeComponents fails on many MSL models because of missing function evaluation
comment:7 in reply to: ↑ 5 Changed 7 years ago by perost
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.
comment:8 in reply to: ↑ 3 ; follow-up: ↓ 9 Changed 7 years ago by 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?)
comment:9 in reply to: ↑ 8 Changed 7 years ago by 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.
comment:10 Changed 7 years ago by casella
- Milestone changed from 2.0.0 to 1.13.0
- Resolution set to fixed
- Status changed from new to closed
All the reported example now issue meaningful error messages. I'll re-open a specific ticket on those errors
Performance info is only given for completed phases, i.e. NFInst.instExpressions completed successfully in this case.