Opened 8 years ago
Closed 8 months ago
#4288 closed defect (fixed)
A submodel is shown in a model diagram while its pathname is wrong and the model doesn't simulate
| Reported by: | massimo ceraolo | Owned by: | Adrian Pop |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Interactive Environment | Version: | |
| Keywords: | Cc: | Adeel Asghar, Adrian Pop, Per Östlund |
Description (last modified by )
Consider the model InvPwmPQ in the attached package invPwmPkg.
I'm not sure whether its sub-model PwmPulser has a valid pathname.
But whatever the answer OMEdit seems inconsistent:
1) its icon is visible in the InvPwmPQ diagram
2) when the model is checked the following error is issued:
Error [invPWMPkg: 12:5-12:156]: Class invPWMPkg.PwmPulser not found in scope invPWMPkg.InvPwmPQ.
I think that if PwmPulser is not in scope, its icon should not be visible.
* A later addition: comment 3 explains that PwmPulser is not in scope, and therefore it should not be visible in InvPwmPQ.
Attachments (1)
Change History (26)
by , 8 years ago
| Attachment: | invPWMPkg.mo added |
|---|
comment:1 by , 8 years ago
| Cc: | added |
|---|
comment:2 by , 8 years ago
| Cc: | added; removed |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:3 by , 8 years ago
| Cc: | added; removed |
|---|
comment:4 by , 8 years ago
| Cc: | added; removed |
|---|
comment:5 by , 8 years ago
Ah. I did see that removing invPWMPkg prefix made the model solvable, but failed to track down this to the encapsulated keyword.
Naturally, the core of this ticket was consistency in OM behaviour (so perost's last sentence).
I must add that I'me pretty sure that somehow invPWMPkg prefix was created by OMEdit itself. If confirmed, that is another issue. I will try to produce an example to reproduce this.
comment:6 by , 7 years ago
| Milestone: | 1.12.0 → 1.13.0 |
|---|
comment:8 by , 5 years ago
| Milestone: | 1.14.0 → 1.16.0 |
|---|
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0
comment:9 by , 5 years ago
| Description: | modified (diff) |
|---|---|
| Summary: | A path issue → A submodel is shown in a model diagram while its pathname is wrong and the model doesn't simulate |
follow-up: 11 comment:10 by , 4 years ago
@perost, I retried this with the latest nightly, and the model is compiled without a hiccup.
Does this mean that neither the NF, nor the API, handle lookup in encapsulated packages correctly?
comment:11 by , 4 years ago
Replying to casella:
@perost, I retried this with the latest nightly, and the model is compiled without a hiccup.
Does this mean that neither the NF, nor the API, handle lookup in encapsulated packages correctly?
Seems we've forgotten to implement support for encapsulated in the NF entirely. I'll fix it tomorrow.
comment:14 by , 4 years ago
| Owner: | changed from to |
|---|
follow-up: 16 comment:15 by , 4 years ago
| Cc: | added |
|---|
@perost, @adrpo, is this because the API uses the old frontend?
comment:16 by , 4 years ago
Replying to casella:
@perost, @adrpo, is this because the API uses the old frontend?
No, the old frontend gives the same error. This is an API issue.
comment:17 by , 4 years ago
| Component: | OMEdit → Interactive Environment |
|---|---|
| Owner: | changed from to |
Then should @adrpo take care of this?
comment:18 by , 4 years ago
The OMC/OMEdit graphical API doesn't care if a model can check/simulate or not. Is only interested in fetching model annotations and displaying them. If we are to enforce all the rules, most of the incomplete models would not display due to missing constants, etc.
In this particular case the OMC/OMEdit graphical API doesn't use the lookup of the old or the new front-end, it just goes into the AST and gets the class using the given path.
Aslo, with regards to comment comment5, this is ticket #4372.
comment:19 by , 4 years ago
I understand that you feel like thinking general, and in general we cannot ensure that a displayed model checks.
But I think we must consider the user experience as well. If the user sees a submodel and when checking OM cannon see it, he is really disappointed.
This, for me, is totally different from when a model does not check because of a hidden model flaw.
comment:20 by , 4 years ago
I do not fully agree with comment:18. In fact, we are not talking about whether or not a model can simulate, but about a more fundamental issue, i.e. a type error, which is not caught by the OMEdit API.
If I open the test case with Dymola, the pwmPulser object is crossed out, and if I hover on it I get the message "Did not find type invPWMPkg.PwmPulser for component pwmPulser", which is exactly what we only get in OMEdit when we check the model.
That said, we have at least one hundred issues of much higher priority regarding the user experience, so I'd keep this ticket with priority normal.
comment:21 by , 4 years ago
Ok. I get the message. We can enforce some of these checks while searching for the class and maybe even displaying an error message.
comment:23 by , 4 years ago
| Milestone: | 1.17.0 → 1.18.0 |
|---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
comment:25 by , 8 months ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Today this iossue is not present anymore.
The model is invalid, because looking up invPWMPkg requires going to the scope outside invPWMPkg. But since invPWMPkg is encapsulated that's not allowed. So to fix the model, just remove the invPWMPkg prefix from the pwmPulser component.
The icon lookup doesn't seem to follow those rules though, so that should be fixed.