Opened 4 years ago

Closed 4 years ago

#6374 closed defect (fixed)

Issues with the NF in TILMedia

Reported by: Francesco Casella Owned by: Per Östlund
Priority: high Milestone: 1.18.0
Component: New Instantiation Version: 1.18.0-dev
Keywords: Cc:

Description

Please check the latest TILMedia test report. 5 models currently fail during flattening.

Some models fail with

Error: Class ClaRa.Basics.Units.ShearModulus not found in scope BaseSolid.

which I guess is due to the use of classes from a partial package. @perost, can you please confirm?

Some others instead fail during NFConvertDAE with this kind of error

[/var/lib/jenkins/ws/OpenModelicaLibraryTestingWork@2/OpenModelica/OMCompiler/Compiler/NFFrontEnd/NFExpression.mo:2008:11-2008:118:writable] Error: Internal error NFExpression.toDAE got unknown expression '10'

which is kind of weird, since '10' looks like a rather straightforward expression :)

@perost, could you give a quick look before Feb 15? We have a meeting then where the support of this library will be involve

Change History (3)

in reply to:  description ; comment:1 by Per Östlund, 4 years ago

Replying to casella:

Some models fail with

Error: Class ClaRa.Basics.Units.ShearModulus not found in scope BaseSolid.

which I guess is due to the use of classes from a partial package. @perost, can you please confirm?

If it was due to a partial package it would give an error saying so. In this case the name simply doesn't exist, i.e. there's no package called ClaRa in the library and the library has no uses annotation for a library called ClaRa.

Some others instead fail during NFConvertDAE with this kind of error

[/var/lib/jenkins/ws/OpenModelicaLibraryTestingWork@2/OpenModelica/OMCompiler/Compiler/NFFrontEnd/NFExpression.mo:2008:11-2008:118:writable] Error: Internal error NFExpression.toDAE got unknown expression '10'

which is kind of weird, since '10' looks like a rather straightforward expression :)

Fixed in PR 7142.

When you get unknown expression that look normal they're almost always mutable expressions, i.e. expressions wrapped in a pointer type so they can be updated destructively. They're often used in the NF when iterators are involved, since it makes it much more efficient to e.g. unroll for-loops or expand array constructors.

They're only supposed to be used locally during such operations and then changed back to be immutable, but sometimes they escape and cause havoc elsewhere. In this case because we didn't simplify the arguments of external function calls, which caused mutable expressions to escape when expanding an array constructor with an external function call inside.

in reply to:  1 comment:2 by Francesco Casella, 4 years ago

Replying to perost:

Replying to casella:

Some models fail with

Error: Class ClaRa.Basics.Units.ShearModulus not found in scope BaseSolid.

which I guess is due to the use of classes from a partial package. @perost, can you please confirm?

If it was due to a partial package it would give an error saying so.

Of course the compiler is always right ;)

In this case the name simply doesn't exist, i.e. there's no package called ClaRa in the library and the library has no uses annotation for a library called ClaRa.

Sure. I was fooled by the BaseSolid class name, that seemed to imply some (likely partial) base class. I understand ClaRa depends on TILMedia rather than the other way round, I guess that cross-dependency is a mistake. I'll open a ticket about that.

in reply to:  1 comment:3 by Francesco Casella, 4 years ago

Resolution: fixed
Status: newclosed

Replying to perost:

When you get unknown expression that look normal they're almost always mutable expressions, i.e. expressions wrapped in a pointer type so they can be updated destructively. They're often used in the NF when iterators are involved, since it makes it much more efficient to e.g. unroll for-loops or expand array constructors.

They're only supposed to be used locally during such operations and then changed back to be immutable, but sometimes they escape and cause havoc elsewhere. In this case because we didn't simplify the arguments of external function calls, which caused mutable expressions to escape when expanding an array constructor with an external function call inside.

Sounds good. Thanks for the quick feedback!

Note: See TracTickets for help on using tickets.