OMEdit dislays info messages very slowly

[massimo ceraolo]

Te fmu that I enclose runs correctly in OM. I run it from OMEdit.

However there is a strange thing:
before starting actual simulation, OM finds 354 glitches for which it emits warnings. What is really strange is that to show these 354 warnings the program (on my computer) spends as much as 36 seconds, while the time needed for the actual simulation is only 32 seconds!

I wonder whether there is some simple modification allowing faster message display.

[massimo ceraolo]

Maybe the issue has another aspect.
Consider the model:

model test
  Real x;
  parameter Real param = 1;
equation
  x = param * time;
end test;

The row:

parameter Real param = 1;

becomes, in the FMU generated by OM :

parameter Real param(start = 1.0, fixed = true);

The latter row creates a warning when the fmu is executed by OM.
If we have hundreds of parameters, this causes hundred of warnings are issued, creating a huge slowdown.

In addition (or as an alternative) of making warning display more efficient, an additional action maybe can be considered.

=> Either it is correct to convert converting the parameter value, as stated in the binding equation, into a start-fixed value, and in this case no warning should be issued when the fmu is executed,
=> or it is not normal practice, and in this case the FMI creation SW should be fixed.

Tests were made with r20668-RML

[Adeel Asghar]

I agree. This is a general problem with Qt's list with many items. The rendering of items makes the application response time very slow. To make this more worse I have customized list to show multi line messages which doubles the response time.

I propose that we should change the MessagesBrowser to a normal text/console window. This will make things a little better but still when the content of this window gets very huge then we might have performance slow down. The standard behavior of IDE's is to have a text limit on how much to display. For example, if you look at eclipse it has a text limit of 80000 characters when the output increase this size eclipse will start removing the output from the top.

I think a text based console window with characters limit will solve the problem.

[massimo ceraolo]

Yes. I expect a text based console to be several times faster.
A fifo limit on characters is also good.
Another option that might be considered (I've seen sometimes, I believe in in some compiler) is that when the same message occurs several times it stops to be outputted. This reduces the amount of the output. After all the user doesn't want to see hundreds of lines all equal. If after, say 20-40 lines similar to each other, a row like "1500 more such messages" might be better.
If this technique is implemented, the limit on the console size (that is advisable to implement) might be reached only very rarely.

BTW, since you are also the expert of FMU, can you also have a look to my "comment 1"? I think it shows an issue, but I'm not sure what the issue really is.

[Lennart Ochel]

I think the messages are not equal, since the parameter name and its start-value is part of the message. Otherwise identical messages get skipped already, as far as I know.
I agree that parameters should get exported with a binding instead of a start and fixed attribute combination. Therewith, the warnings will disappear anyway.

[Adeel Asghar]

Replying to ceraolo:

Yes. I expect a text based console to be several times faster.
A fifo limit on characters is also good.
Another option that might be considered (I've seen sometimes, I believe in in some compiler) is that when the same message occurs several times it stops to be outputted. This reduces the amount of the output. After all the user doesn't want to see hundreds of lines all equal. If after, say 20-40 lines similar to each other, a row like "1500 more such messages" might be better.
If this technique is implemented, the limit on the console size (that is advisable to implement) might be reached only very rarely.

BTW, since you are also the expert of FMU, can you also have a look to my "comment 1"? I think it shows an issue, but I'm not sure what the issue really is.

I will check it.

[Adeel Asghar]

Replying to ceraolo:

Yes. I expect a text based console to be several times faster.
A fifo limit on characters is also good.
Another option that might be considered (I've seen sometimes, I believe in in some compiler) is that when the same message occurs several times it stops to be outputted. This reduces the amount of the output. After all the user doesn't want to see hundreds of lines all equal. If after, say 20-40 lines similar to each other, a row like "1500 more such messages" might be better.
If this technique is implemented, the limit on the console size (that is advisable to implement) might be reached only very rarely.

BTW, since you are also the expert of FMU, can you also have a look to my "comment 1"? I think it shows an issue, but I'm not sure what the issue really is.

r23669 fixes the FMU warnings. Note that you are using co-simulation FMU with OM which is not fully supported yet.

[Adeel Asghar]

In r23862 the info messages is changed from tree view to text. Options to add the fifo limit of characters will be added soon.

[Adeel Asghar]

You can now set output limit to messages starting from r23882. You can even set more options like font and colors for different kind of messages via Tools->Options->Messages.

[Dietmar Winkler]

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.