Opened 11 years ago

Last modified 5 years ago

#2664 reopened defect

Probelm with handling "when statement" in an FMU

Reported by: uzahsan@… Owned by: Willi Braun
Priority: high Milestone: Future
Component: FMI Version: trunk
Keywords: Cc: Lennart Ochel, Karim Adbdelhak, Andreas Heuermann

Description

There has been a problem with models involving "when statements". The modelica code of these models work fine but the problem manifests itself once the model is exported as an FMU and then re-imported for simulation.
Running simulations after re-importing the FMU show that when conditions in the model never get fired at all.

Attachments (5)

SimpleTest.mo (1.1 KB ) - added by Adeel Asghar 11 years ago.
test.mo (835 bytes ) - added by Adeel Asghar 11 years ago.
script.mos (362 bytes ) - added by Adeel Asghar 11 years ago.
test_res.png (16.2 KB ) - added by Karim Adbdelhak 5 years ago.
test_res.mat (22.5 KB ) - added by Karim Adbdelhak 5 years ago.

Download all attachments as: .zip

Change History (24)

by Adeel Asghar, 11 years ago

Attachment: SimpleTest.mo added

by Adeel Asghar, 11 years ago

Attachment: test.mo added

by Adeel Asghar, 11 years ago

Attachment: script.mos added

comment:1 by Adeel Asghar, 11 years ago

Cc: Willi Braun added

I have attached a test case.

comment:2 by Willi Braun, 11 years ago

Owner: changed from Adeel Asghar to Willi Braun
Status: newaccepted

The fmi-export doesn't work well at all i.e. testsuite/openmodelica/fmi/ModelExchange/testInOutTest.mos is totally wrong. We can't use the ringbuffer for the exported model, since we can't assure the correct handling by the calling programs.

But the issue here is mostly fmi-import, since the function fmiEventUpdate needs a call every time a discrete variable is changing.
Further there are serious problem, with the compile-time and simulation-time with our fmi-import.

comment:3 by Willi Braun, 11 years ago

in r20190 fixed some fmi export issues e.g. testsuite/openmodelica/fmi/ModelExchange/testInOutTest.mos works correctly again.

comment:4 by Willi Braun, 11 years ago

Some of the performance issue are owed by ticket #2669.

comment:5 by Martin Sjölund, 10 years ago

Milestone: 1.9.11.9.2

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

comment:6 by Martin Sjölund, 10 years ago

Milestone: 1.9.21.9.3

Milestone changed to 1.9.3 since 1.9.2 was released.

comment:7 by Martin Sjölund, 9 years ago

Milestone: 1.9.31.9.4

Moved to new milestone 1.9.4

comment:8 by Martin Sjölund, 9 years ago

Milestone: 1.9.41.9.5

Milestone pushed to 1.9.5

comment:9 by Martin Sjölund, 9 years ago

Milestone: 1.9.51.10.0

Milestone renamed

comment:10 by Martin Sjölund, 8 years ago

Milestone: 1.10.01.11.0

Ticket retargeted after milestone closed

comment:11 by Martin Sjölund, 8 years ago

Milestone: 1.11.01.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:12 by Francesco Casella, 7 years ago

Milestone: 1.12.0Future

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.

comment:13 by Willi Braun, 7 years ago

Milestone: Future1.13.0
Resolution: fixed
Status: acceptedclosed

This seems to be fixed in the meanwhile.

comment:14 by yahooprimkins@…, 5 years ago

This problem seems not fixed. The problem can be seen in the 1.14 official release version.

by Karim Adbdelhak, 5 years ago

Attachment: test_res.png added

by Karim Adbdelhak, 5 years ago

Attachment: test_res.mat added

comment:15 by Karim Adbdelhak, 5 years ago

Tested it with 1.16.0~dev-95-g92c3b53 (nightly) and it seems to work fine (see attached files test_res.mat and test_res.png). At it least it does what i expected. Could you attach your results?

I downloaded the three files and just run it from terminal on ubuntu.

EDIT: Ah no ... i looked at the wrong line in the plot, you are right it seems wrong!

Last edited 5 years ago by Karim Adbdelhak (previous) (diff)

comment:16 by Karim Adbdelhak, 5 years ago

Cc: Lennart Ochel Karim Adbdelhak Andreas Heuermann added; Willi Braun removed
Milestone: 1.13.0Future
Resolution: fixed
Status: closedreopened

comment:17 by Karim Adbdelhak, 5 years ago

@lochel, @AnHeuermann, could you have a look at this?

comment:18 by Andreas Heuermann, 5 years ago

The FMI import is deprecated, use OMSimulator instead.
We should add a warning for this, since it simply doesn't work.
But I am not completely sure how to do this with OMSimulator scripting and OMEdit keeps crashing when I try to use it (see #5785).

Replacing when change(u) then with when u > pre(u) or u < pre(u) then or when u>pre(u) then doesn't help here.

So it is probably no problem regarding the change key-word, or the combination of two condition literals.

Last edited 5 years ago by Andreas Heuermann (previous) (diff)

in reply to:  18 comment:19 by Francesco Casella, 5 years ago

Replying to AnHeuermann:

The FMI import is deprecated, use OMSimulator instead.
We should add a warning for this, since it simply doesn't work.

Absolutely!

However, please see the discussion starting in ticket:5621#comment:20

I don't think that banning FMI import is a good idea.

Note: See TracTickets for help on using tickets.