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 Francesco Casella, 6 years ago

Cc: dr.christian.kral@… added

comment:2 by Per Östlund, 6 years ago

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.

comment:3 by Francesco Casella, 6 years ago

I see, in fact I was still using a nightly from Jan 9. Thanks for looking into it.

comment:4 by Per Östlund, 6 years ago

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.