Opened 5 years ago

Closed 5 years ago

#5277 closed defect (fixed)

Issue with NFtyping and arrays of literals

Reported by: casella Owned by: perost
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 Changed 5 years ago by casella

  • Cc dr.christian.kral@… added

comment:2 Changed 5 years ago by perost

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 Changed 5 years ago by casella

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

comment:4 Changed 5 years ago by perost

  • Resolution set to fixed
  • Status changed from new to 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.

Note: See TracTickets for help on using tickets.