Opened 5 years ago

Last modified 3 years ago

#5682 assigned defect

Provide information about wrong graphical annotations when checking models in OMEdit

Reported by: Francesco Casella Owned by: Adrian Pop
Priority: critical Milestone:
Component: Interactive Environment Version:
Keywords: Cc: Lennart Ochel, Per Östlund

Description

Some time ago, we decided to suppress a lot of warnings issued by OMC when interacting with OMEdit, that were really confusing for end-users, who just saw lots of issues without having any means to understand them, let alone fix them. See #5048.

I think this is the correct approach from an end-user perspective.

Hoever, @lochel correctly pointed out that, in his role of library developer, he does not get any error message regarding wrong graphical annotations, which however has serious consequences (-> wrong diagram displayed).

This is demonstrated by the attached model, which has a wrong annotation (exxtent is misspelled). This has a consequence on the displayed diagram (which uses the default extent instead), but there is no way to have OMEdit report where the problem is.

We agreed that the best solution is that those messages are normally suppressed, but are indeed shown when the model is checked. I'm not sure if this should be done by the frontend, or if rather some extra API call should be performed after checking, without suppressing the output.

@adeas31, can you please take care of that?

Attachments (1)

M.mo (261 bytes ) - added by Francesco Casella 5 years ago.

Download all attachments as: .zip

Change History (10)

by Francesco Casella, 5 years ago

Attachment: M.mo added

comment:1 by Francesco Casella, 5 years ago

Cc: Lennart Ochel added

comment:2 by Adeel Asghar, 5 years ago

The referenced ticket is wrong. In #5048 we fixed mostly the warning messages coming from Qt. The correct ticket is #5565. When -d=nfAPI is used it prints a lot of warnings so we added a flag -d=nfAPINoise (which is false by default) to suppress them.

These warning messages are only generated when fetching the annotations. So enabling the flag before check model is not going to help.

I can make this a setting in OMEdit. So by default it will remain disabled but the user can enable it if needed. And then I will write some information about it in the users guide. What do you think?

in reply to:  2 comment:3 by Francesco Casella, 5 years ago

Replying to adeas31:

These warning messages are only generated when fetching the annotations. So enabling the flag before check model is not going to help.

Standardized annotations listed in Chapter 18 of the specification should be accepted. Of course we should in general ignore all vendor annotations except __OpenModelica ones, except when we have good reasons to do otherwise.

Anything else used in annotations should IMHO generate an error. There is no reason why we should accept models with wrong annotations.

@perost, what do you think?

I can make this a setting in OMEdit. So by default it will remain disabled but the user can enable it if needed. And then I will write some information about it in the users guide. What do you think?

I don't think this is the right way to go. Mistyped annotations should be caught immediately when checking models, and this is definitely not an advanced feature. To the contrary, it is mostly needed by beginners.

Last edited 5 years ago by Francesco Casella (previous) (diff)

comment:4 by Francesco Casella, 5 years ago

We discussed this issue during today's devmeeting. The correct way to solve this is to actually instantiate the annotations of models, so as to be able to typecheck them during the check phase.

In the meantime we could add a setting in OMEdit so that expert developers such as @lochel can turn on again the error reporting when the API fetches graphical annotations for GUI rendering.

comment:5 by Adeel Asghar, 5 years ago

Component: OMEditInteractive Environment
Owner: changed from Adeel Asghar to Adrian Pop
Status: newassigned

Added an OMEdit setting in 0a7b784/OpenModelica.

comment:6 by Francesco Casella, 4 years ago

Milestone: 1.15.01.16.0

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

comment:7 by Francesco Casella, 4 years ago

Milestone: 1.16.01.17.0

Retargeted to 1.17.0 after 1.16.0 release

comment:8 by Francesco Casella, 4 years ago

Milestone: 1.17.01.18.0

Retargeted to 1.18.0 because of 1.17.0 timed release.

comment:9 by Francesco Casella, 3 years ago

Milestone: 1.18.0

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.