Opened 6 years ago
Closed 6 years ago
#5277 closed defect (fixed)
Issue with NFtyping and arrays of literals
Reported by: | Francesco Casella | Owned by: | Per Östlund |
---|---|---|---|
Priority: | high | Milestone: | 2.0.0 |
Component: | New Instantiation | Version: | |
Keywords: | Cc: | dr.christian.kral@… |
Description
Please consider the attached test package, provided in #4297.
When compiling MutualInductorTest
, the NF fails with
[1] 11:14:58 Translation Error [C:/dev/OM64bit/OMCompiler/Compiler/NFFrontEnd/NFTyping.mo: 1113:9-1113:121]: Internal error NFTyping.typeExp got unknown expression: {1, 2, 3, 4}
Change History (4)
comment:1 by , 6 years ago
Cc: | added |
---|
comment:2 by , 6 years ago
comment:3 by , 6 years ago
I see, in fact I was still using a nightly from Jan 9. Thanks for looking into it.
comment:4 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
It turns out the issue was that we didn't do any type checking of the reduction expression in the NF. With the changes I'm currently pushing in the NF now gives an error message instead:
[MutualInductanceTesting.mo:67:7-67:52:writable] Error: Invalid expression ‘j * mutualInductor.omega * mutualInductor.L[j, k] * mutualInductor.i[k]‘ of type ‘Complex‘ in sum reduction, expected Integer or Real.
This is based on 10.3.4.1 in the Modelica specification that explicitly says that the argument of a sum reduction must be an Integer or Real expression.
One might expect that the reduction operators would work on operator records with the appropriate operator too, but this is not specified anywhere. I did quickly check what would happen if the NF actually allowed it, and the model actually passed the backend but failed during compilation since I didn't change the fold expression we generate (i.e. it was still trying to use +
instead of the '+'
-operator from Complex).
Anyway, the reported issue has already been fixed as mentioned, so I'm closing this ticket. Further discussion on Complex reductions can be done in #4297.
This was actually fixed a couple of days ago, in 282e64e. The model now fails without an error message during DAE conversion instead. I'll take a look at that, might be something easy to fix.