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)
follow-ups: 2 3 comment:1 by , 4 years ago
comment:2 by , 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.
comment:3 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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!
Replying to casella:
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.
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.