#2079 closed enhancement (fixed)
OMEdit does not handle replaceable classes and components
Reported by: | Francesco Casella | Owned by: | Adrian Pop |
---|---|---|---|
Priority: | blocker | Milestone: | 1.16.0 |
Component: | OMEdit | Version: | trunk |
Keywords: | Cc: | dersh@…, Andrea Bartolini |
Description
Many models in the MSL and in other Modelica libraries heavily rely on replaceable classes and components. One example could be the Modelica.Fluid.Machines.Pump model, which contains three replaceable functions for the pump characteristic curves, or the Modelica.Fluid.Vessels.ClosedVolume, which contains a replaceable model for the heat transfer model.
As of today, these replaceable classes and components are simply ignored by OMEdit, making the models that contain them totally unusable, unless one knows exactly how the model is built internally and writes the appropriate redeclare statement manually - this restricts the usage of those parts of the MSL library to their developers, which is obviously not a good idea.
For a good user experience, two features are necessary. First of all, for each replaceable class or component, the user should be able to select a class which is compatible with the constraining class, either specified explicitly by the choices annotation (see Section 7.3.4 of the language specification), or by the choicesAllMatching annotation, which should also become part of the spec, as it is widely used in the MSL.
Second, once a specific class has been selected, it should be possible to set its parameters, and possibly to recursively set its replaceable classes, as one replaceable class can contain another replaceable class.
In Dymola, the first choice is made by a drop-down list, while the second can be made by clicking on a button side-by-side with the list, which opens a new window containing all the parameters and replaceable classes of the selected class. Of course we can do it differently, but I don't see many other options to handle this.
Attachments (1)
Change History (61)
follow-ups: 3 4 comment:1 by , 11 years ago
Milestone: | → 2.0.0 |
---|
comment:2 by , 11 years ago
comment:3 by , 11 years ago
Replying to casella:
Please prioritize this issue. This is the primary issue which prevents my organization from benefiting from the OpenModelica suite of tools.
comment:4 by , 11 years ago
Replying to casella:
Please do the needful as soon as possible. I encountered the same problem while using the MSL fluids library where you cannot know that the medium of flow has been set unless you go to the Modelica Text View and look at it. Spent hours thinking why my model wasnt solving but later found out that the fluid models were missing the redeclare package Medium = Modelica.Media.Water.ConstantPropertyLiquidWater in them. This cannot be found anywhere in the Parameters tab.
comment:5 by , 11 years ago
Cc: | added |
---|
comment:6 by , 10 years ago
Milestone: | 2.0.0 → 1.9.2 |
---|
comment:7 by , 10 years ago
+1 on this, I lost more time than I like to think about until I found out that I manually have to add appropriate redeclare statements to most fluid components.
comment:10 by , 10 years ago
Milestone: | 1.9.2 → 1.9.3 |
---|
Milestone changed to 1.9.3 since 1.9.2 was released.
comment:11 by , 9 years ago
I believe this is to pushed to 1.9.4 or later, as 1.9.3 have just been released.
comment:13 by , 9 years ago
How strong is the commitment to solve this issue for 1.9.4? It has been postponed several times already.
comment:14 by , 9 years ago
Considering it was batch moved to 1.9.4, I guess not very. Possibly all tickets should have been moved to empty milestone instead...
comment:15 by , 9 years ago
This is currently top priority, and I understand most of the needed functionality is already in place, Adrian and Adeel please comment.
The move to 1.9.4 was inevitable, as 1.9.3 has been released and we don't have a time machine at hand :)
comment:16 by , 9 years ago
I believe this is the same problem I am having with
Modelica->Mechanics->Translational->Components->MassWithStopAndFriction
Clearly this is something with broad impact on many parts of MSL. I believe it deserves the high priority it has been given.
follow-up: 18 comment:17 by , 9 years ago
We installed OM 1.9.4 and still can't make a connection to a partial class. So what is the REAL milestone now? And can we also get an indicative date for that milestone? Thanks
comment:18 by , 9 years ago
Replying to roel:
We installed OM 1.9.4 and still can't make a connection to a partial class. So what is the REAL milestone now? And can we also get an indicative date for that milestone? Thanks
Sorry, mistake, it seems to be 1.9.3. So it's still scheduled to be in 1.9.4?
comment:21 by , 9 years ago
Priority: | critical → blocker |
---|
The ticket might have been critical three years ago, when many more issues hindered the practical use of OpenModelica. Meanwhile it is a major blocker.
comment:22 by , 9 years ago
I'm not sure I understand the distinction between "critical" and "blocker." I just consider it "majorly embarrassing." This bug keeps OMEdit from connecting longstanding components in the Modelica Standard Library. This means that we have to tell beginners that "you can't really use some of the interesting parts of the system until you become a fully competent Modelica programmer and can deal with the workarounds."
Of course, I very much appreciate the great effort of the developers who make this code available. I admit to being frustrated to see it be almost good enough for real use, and with apparently no attention for three years.
follow-up: 25 comment:23 by , 9 years ago
@sct12: blocker means there will not be a new release without solving this.
With limited resources is always the case to choose between better Modelica coverage and the GUI.
comment:24 by , 9 years ago
Milestone: | 1.10.0 → 2.0.0 |
---|
At the last Board meeting, the decision was that a minor 1.10 release should be done once the 64-bit Windows build is deemed to be stable enough. This should be very soon, as no complaints have been reported so far on that.
The support of replaceable, together with higher library coverage, is the main requirement for releasing 2.0.
I have updated the ticket to reflect this decision correctly.
comment:25 by , 9 years ago
Replying to adrpo:
With limited resources is always the case to choose between better Modelica coverage and the GUI.
At this point I would give higher priority to the GUI support of replaceable. BTW, this task has already been set to very high priority by the Board for the next development increment (Mar-May 2016).
Better coverage of libraries can be achieved incrementally, and maybe OMC is already good enough for many practical applications. On the other hand, no support for replaceable means that Modelica.Media and Modelica.Fluid are really non-intuitive to use, in particular for beginners. Getting this feature is a binary achievement: either we have it or we don't.
comment:26 by , 9 years ago
Owner: | changed from | to
---|---|
Status: | new → accepted |
follow-up: 28 comment:27 by , 8 years ago
Milestone: | 2.0.0 → 1.11.0 |
---|
It was not known that 1.11 would come and it was not possible to select 1.11 when the milestone was changed to 2.0 in comment:24.
comment:28 by , 8 years ago
Milestone: | 1.11.0 → 2.0.0 |
---|
Replying to rfranke:
It was not known that 1.11 would come and it was not possible to select 1.11 when the milestone was changed to 2.0 in comment:24.
comment:24 had a very clear rationale: this feature is a must have for 2.0.0 (thus it is a blocker), but it shouldn't have blocked the release of 1.10, which should have contained the 64-bit Windows version, that is a major improvement in terms of stability for OMEddit (see #3868).
In the meantime, 1.10 was cancelled, and after 7 months we still do not have a stable release with 64-bit Windows version, so a fortiori this ticket shouldn't be a blocker for 1.11, which should be released ASAP.
follow-up: 45 comment:29 by , 8 years ago
@adrpo, please consider this simple test case
package Test model M A a(redeclare model D = B(p=2, q=3)) annotation (Placement(transformation(extent={{-26,-4},{-6,16}}))); end M; model A replaceable model D = B1 constrainedby C annotation(choicesAllMatching=true); D d; end A; model B1 extends C(p = 3); parameter Real q = 4; end B1; model B2 extends C(p = 5); parameter Real r = 10; end B2; model C parameter Real p = 0; end C; end Test;
Can you already handle model M, i.e.
- show the replaceable class D in the parameter dialog
- show C, B1, and B2 in the drop-down list of possible replacement
- show and change the relevant parameters once the choice has been made?
If so, I would recommend that you commit what you have to master, and possibly ask Adeel to add a flag (default to false) to enable the replaceable model dialog, so that people only use this if they know what they're doing.
This functionality would already be enough for some of our applications, and would allow us to start testing right away.
Thanks!
comment:30 by , 8 years ago
Cc: | added |
---|
comment:31 by , 7 years ago
Milestone: | 2.0.0 → 1.13.0 |
---|
@adrpo, can you quiclky summarize the status of this issue for the general public?
follow-up: 33 comment:32 by , 7 years ago
I'm currently upgrading an old library and want to make it OMEdit compatible. So I'm very interested as to what the status is. I.e., how many library features I need to remove in order that the user experience does not suffer when using OMEdit.
comment:33 by , 7 years ago
Replying to dietmarw:
I'm currently upgrading an old library and want to make it OMEdit compatible.
There is no such thing as an OMEdit compatible library. It is OMEdit that needs to be 100% Modelica compliant!
#2894 collects all known issues with OMEdit GUI usability. If you want to make your library fully functional with OMEdit today, you can refer to that. However, the plan is to have all those issues fixed in version 2.0.0, which will be rolled out some time next year when the new front end is fully functional.
comment:34 by , 7 years ago
With OMEdit compatible I meant restricting the used standard features of Modelica to those that are currently supported. Unfortunately I can not wait for 2.0.0 in this instance since I need the library to be usable earlier.
#2894 was exactly the ticket that guided me here. Still would be nice to know what the status of 1.13.0 dev is.
follow-up: 39 comment:38 by , 5 years ago
This may be the most wanted missing feature in OMEdit, so I guess many people are following this ticket. Just by reading it, you may think that after 6 years we are really not paying attention to our end users' needs, or maybe that we are just plain crazy.
In fact, we are not :)
I will provide some more context information in this comment.
OMEdit doesn't really understand Modelica code. Rather, it takes all the information that it displays from the OMC frontend via API calls. When this ticket was opened 6 years ago, the frontend was the result of the evolution of the original codebase started in 2003. We thought it could be used to manage replaceable classes, but sadly it turned out it was not up to the task.
In 2016, a major effort was started to develop a new frontend (NF) for OMC from scratch, see #4138 and the Modelica Conference paper on the topic. The main goals were
- using new MetaModelica 3.0 features
- achieve complete coverage of Modelica language features
- much higher speed
- keep arrays as such, so as to enable efficient code generation for large-scale models containing arrays
The development of the NF is mostly complete, the only missing feature is correct handling of arrays of records, which turned out to be a lot more challenging than expected because arrays are no longer flattened to scalars. The NF will be the default option in OMEdit in 1.14.0, with a fallback to the old one in case the compilation fails.
A couple of years ago, @adrpo started to use the NF to implement the support for replaceable models, and more in general to re-implement those API functions that were too slow and made using the OMEdit GUI a pain in some cases. This has already led to significant improvements, see, e.g., #2690, which are available by default in the latest nightly builds of version 1.14.0.
The original plan assumed that only some parts of the NF would be necessary, so we could get this feature before the NF was complete. It turned out this was not the case, so we had to wait for the NF to be nearly complete. Additionally, the implementation was plagued by several issues that caused OMC to crash, which is not something we want to see in any of our next releases. @adrpo has been fighting with that for a long time. He is now testing the API on all the Modelica Standard Library models that have replaceable classes and fixing the remaining bugs, and we finally see the end in sight. It goes without saying that we are only going to release this feature when it is rock-solid.
The current plan is to release 1.14.0 beta as soon as all remaining bugs with replaceable support have been fixed, as well as a couple more long-standing issues (#2081,
#2661) that should be straightforward to fix with the current infrastructure ready.
The plan was to carry this out by end of July. As one of the corollaries of Murphy's law says: there is always one more bug, so this may actually take a bit longer, but it shouldn't be much.
comment:39 by , 5 years ago
Replying to casella:
In fact, we are not :)
...
The plan was to carry this out by end of July. As one of the corollaries of Murphy's law says: there is always one more bug, so this may actually take a bit longer, but it shouldn't be much.
I just want to thank you for all your work!
It took some time to get me here and finally to get undestanding about replaceble classes. It is really confusing for me as a new user to get started with Fluid library without this feature. All promises about physical modelling by just connecting models is broken and where is no way for new user to get answers why it is not working.
It is good to have Examples - they almost work - but without step-by-step instructions how to reproduce them it is very hard build your own models - you just don't know which parameter is critical and which can be left by default to get first simulation results.
comment:40 by , 5 years ago
We should have clarified this issue in the Release Notes long time ago - it was obvious for people who have been involved with the development of the tool for a while, but of course not for beginners.
At this point, the next release is expected to solve the problem for good, coming anytime soon in the nightly builds :)
In fact, we badly need feedback from new users who find some "features" (a.k.a. bugs) of OMEdit puzzling. Many things are obvious to us, but are not for beginners with no prior exposure to Modelica, the Modelica Standard Library, and the OMC/OMEdit quirks.
If there is anything that made you scratch your head and is not already listed in the blocker tickets, please do open a ticket. This helps us a lot developing a better product. The only recommendation for any issue you report is that you should put us in the condition to reproduce it, attaching any test case that could help doing that.
follow-up: 42 comment:41 by , 5 years ago
I work at a United States national lab, and I can say that we'll almost certainly be developing a lot of neat open source modeling tools in OpenModelica if this issue can be solved.
follow-up: 49 comment:42 by , 5 years ago
Replying to anonymous:
I work at a United States national lab, and I can say that we'll almost certainly be developing a lot of neat open source modeling tools in OpenModelica if this issue can be solved.
Good to hear. Can you mention which lab?
In fact, in that case it would be really nice if you lab could join the Open Source Modelica Consortium, thus helping to support the future development of the tool.
comment:43 by , 5 years ago
Thanks a lot for working on this issue since it also is a blocker for us in the library we are developping for our customers. I will try it in the Nightly Build.
Do you have an idea on when an official release including these improvements will be released ?
comment:44 by , 5 years ago
When the remaining bugs in the implementation have been ironed out. Unfortunately it is still work in progress. It is quite difficult to make any reliable prediction of how long that will take.
comment:45 by , 5 years ago
I am a bit confused, or maybe I missed something, but I upgraded OpenModelica to OpenModelica v1.14.0-dev-26739-g57a0101ee7 (64-bit) and this example is still not working. By "still not working" I mean that I do not have a drop-down list in model A in order to redeclare the replaceable model D.
Is there something that I missed ?
Replying to casella:
@adrpo, please consider this simple test case
package Test model M A a(redeclare model D = B(p=2, q=3)) annotation (Placement(transformation(extent={{-26,-4},{-6,16}}))); end M; model A replaceable model D = B1 constrainedby C annotation(choicesAllMatching=true); D d; end A; model B1 extends C(p = 3); parameter Real q = 4; end B1; model B2 extends C(p = 5); parameter Real r = 10; end B2; model C parameter Real p = 0; end C; end Test;Can you already handle model M, i.e.
- show the replaceable class D in the parameter dialog
- show C, B1, and B2 in the drop-down list of possible replacement
- show and change the relevant parameters once the choice has been made?
If so, I would recommend that you commit what you have to master, and possibly ask Adeel to add a flag (default to false) to enable the replaceable model dialog, so that people only use this if they know what they're doing.
This functionality would already be enough for some of our applications, and would allow us to start testing right away.
Thanks!
follow-up: 47 comment:46 by , 5 years ago
The required functionality is not yet in the nightly builds, because it causes some crashes. It won't be pushed there until it is reliable enough.
comment:47 by , 5 years ago
Ok thank you for this information.
Replying to casella:
The required functionality is not yet in the nightly builds, because it causes some crashes. It won't be pushed there until it is reliable enough.
comment:48 by , 5 years ago
Milestone: | 1.14.0 → 1.15.0 |
---|
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.
This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0
comment:49 by , 5 years ago
National Renewable Energy Lab, and I've established that we do have some interest in participating in the Open Source Modelica Consortium, but I don't know if that will turn into action. Sorry for the absurd delay in responding.
Replying to casella:
Replying to anonymous:
I work at a United States national lab, and I can say that we'll almost certainly be developing a lot of neat open source modeling tools in OpenModelica if this issue can be solved.
Good to hear. Can you mention which lab?
In fact, in that case it would be really nice if you lab could join the Open Source Modelica Consortium, thus helping to support the future development of the tool.
comment:50 by , 5 years ago
I hope we can deliver 1.15.0 before the interest turns into action. Unfortunately, we are still getting crashes from this functionality, for reasons that are not completely clear yet.
comment:51 by , 4 years ago
Release 1.15.0 was eventually [ https://trac.openmodelica.org/OpenModelica/milestone/1.15.0 scrapped], because it turned out to be easier to integrate replaceable support in 1.16.0.
The feature was merged in with PR #943, is currently available for testing in the nightly builds, and is scheduled to be released with v. 1.16.0, see #5977.
comment:52 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
comment:53 by , 4 years ago
For the record, the feature is currently optional and disabled by default - it can be enabled with Tools|Options|General|Optional Features|Enable replaceable support. It will be turned on by default once it has been properly tested and debugged.
comment:54 by , 4 years ago
Milestone: | 1.15.0 → 1.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:55 by , 4 years ago
Preliminary support for redeclare/replaceable is now available in the GUI.
comment:56 by , 4 years ago
I currently use OMEdit 1.16.0, which supports the drop-down menu for replaceable models. However, repplaceable packages are not implemented. Can any one tell me which version of OMEdit fixes this implementation yet?
comment:57 by , 4 years ago
What do you mean? It should support packages as well such as PartialMedium (which is a package) and so on. Do you have an example where this doesn't work?
follow-up: 59 comment:58 by , 4 years ago
Also please make sure you checked the Tools | Options | General | Enable Replaceable Support option.
comment:59 by , 4 years ago
Replying to casella:
Also please make sure you checked the Tools | Options | General | Enable Replaceable Support option.
Thank you so much. Replaceable packages appear in drop-down menu after the option is enabled, in OMEdit 1.16.0
comment:60 by , 4 years ago
We will eventually enable that feature permanently. With 1.16.0 we were a bit hesitant, so we did not enable it by default. Unfortunately, any new installation keeps the settings of the previous one, so you need to explicitly activate it.
I strongly back this request. Also, OMEdit does not allow to make connections in models that contain instances of partial classes (because for every graphical connection, a model check is triggered, which fails, an so the connection is not made).