Add interactive simulation support (e.g., DynamicSelect display)

[OpenModelica-TracImporter]

No description provided.

[bilderbuchi]

Effectively duplicate of #5631? Ah no, OM does not yet support all DynamicSelect usages afaict.

[perost]

Original ticket: https://trac.openmodelica.org/OpenModelica/ticket/3675

[adeas31]

This is already done as part of #5631.

[adeas31]

Reopen if you still have issues with DynamicSelect.

[bilderbuchi]

Reopen if you still have issues with DynamicSelect.

Thank you, please reopen then:

I see that DynamicSelect does not survive inheritance apparently - maybe the variable lookup fails in an inherited class?
Simulate the following model:

model Dyamicselect_OM_3675
  model DSBase
  Modelica.Units.SI.MassFlowRate Val;
  equation
    Val = 42 + 10* time;
  
  annotation(
      Icon(graphics = {Text(origin = {-8, 35}, extent = {{-66, 39}, {66, -39}}, textString = DynamicSelect("static", String(Val))), Text(origin = {0, 120}, extent = {{-100, 20}, {100, -20}}, textString = "%name")}));
  end DSBase;

  model DSDerived
    extends Dyamicselect_OM_3675.DSBase;
  equation

  end DSDerived;

  Dyamicselect_OM_3675.DSBase dSBase annotation(
    Placement(visible = true, transformation(origin = {-22, 60}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  Dyamicselect_OM_3675.DSDerived dSDerived annotation(
    Placement(visible = true, transformation(origin = {-22, 26}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
equation

end Dyamicselect_OM_3675;

Observe in the plotting perspective, diagram view, that the text of dSBase changes with time as expected, but dSDerived erroneously shows static.

• OpenModelica Version: OpenModelica v1.19.0-dev-613-gd6e04c0efc (64-bit)
• OS: Windows 10, 64 bit

cf. also #8593

[dietmarw]

I just tried it and I could not get DynamicSelect to work. Also tried the example from #5631 which does not display anything except:

So am I missing some settings that need to get done in OMEdit in order to get DynamicSelect to display? I did try to compile with 3D with no difference and am also not sure if that is still needed to get DynamicSelect working in the first place.

[bilderbuchi]

Just to double-check - you were looking at this in the plotting perspective - diagram view, and using the scrubber/play button?

If you want to avoid an external dependency/library, you can also check with Modelica.Fluid.Examples.Tanks.EmptyTanks, which displays the dynamic level value in the tanks (but does not drop the level/change the size of the blue rectangle)

[dietmarw]

Thanks, I'll check as soon as OMEdit becomes responsive again after trying to open a parameter dialogue. 10 mins and counting ;-)

[adrpo]

Just kill it, most likely you have the old frontend as default. See Options/Simulation/use the old frontend. It should be off.
Check Options/General/bottom, use the new API. It should be on.

[dietmarw]

@adrpo if only. Had to do now 2 hard reset of my machine due to OMEdit completely hogging the system. Looks like some regression in the latest nightlies. Have not experienced this before.

Anyway:
I got the example from Buildings working now but testing it on OpenIPSL.Examples.Machines.PSSE.GEN I can make the following observations:

• DynamicSelect does not work if enabled/disabled via visible
• Does not like to work in combination with function calls.E.g.,

Text(  visible=displayPF,
         extent={{-80,100},{80,20}},
         lineColor={255,0,0},
         textString=DynamicSelect("0.0 MW",
           OpenIPSL.NonElectrical.Functions.displayPower(P, " MW")))

[adrpo]

We don't support functions in DynamicSelect yet. You can use expressions but no function calls as the evaluation is done in OMEdit based on the simulation results and an expression evaluator.

[dietmarw]

What about Polygons which are also not displayed?

Polygon(
          visible=displayPF,
          points=DynamicSelect({{-20,80},{-20,60},{20,70},{-20,80}}, if P >= 0
             then {{-20,80},{-20,60},{20,70},{-20,80}} else {{20,80},{20,60},{-20,
            70},{20,80}}),
          lineColor={255,0,0},
          fillColor={255,0,0},
          fillPattern=FillPattern.Solid)

[adrpo]

I think we always consider visible as true, no matter the value it has. There is a bug open for that.

We started planning the work to fix these things, it requires some major changes to the omc API, but it will fix the long lasting bugs with conditional connectors, annotation and dialog display when based on parameters, etc.

[dietmarw]

But the DynamicSelect part should normally work in his case right? I mean here it is only switching between point values. No function call.

[adrpo]

What about Polygons which are also not displayed?

Polygon(
          visible=displayPF,
          points=DynamicSelect({{-20,80},{-20,60},{20,70},{-20,80}}, if P >= 0
             then {{-20,80},{-20,60},{20,70},{-20,80}} else {{20,80},{20,60},{-20,
            70},{20,80}}),
          lineColor={255,0,0},
          fillColor={255,0,0},
          fillPattern=FillPattern.Solid)

This should probably work fine.

[dietmarw]

Only it does not :-(
Dymola:

OMEdit:

(No idea why OMC calculates different values here but that is a whole different issue)

[dietmarw]

Hard to see, but the green arrows should be pointing the opposite direction.

[adrpo]

Seems like a bug, @adeas31, can you have a look and see if this is an OMEdit thing or OMC problem?

[perost]

Looks like we haven't implemented DynamicSelect for points yet. We do support it for extent though, which is pretty much the same thing except limited to two points. So it shouldn't be much work to implement I think.

[dietmarw]

So maybe time to reopen this issue again? Looks like the following things are still missing:

• Support for functions
• support for points
• support visible (possible different issue)

[bilderbuchi]

Also
* [ ] Correctly deal with inheritance as in my comment above: #3675 (comment) (or should I open a separate issue for that?)

[bilderbuchi]

To separate bugs and feature requests, I reported the inheritance issue separately - #8607

[dietmarw]

Looks like there is a regression in the latest 1.20.0-dev version. Rerunning the example OpenIPSL.Tests.Machines.PSSE.GEN the Vpu and Angle displays will stay static. This used to work before. I've also removed the "visible" part just to make sure that part does not block the dynamicSelect functionality.

[casella]

@adeas31 can you please check, before we branch off 1.20.0?

Thanks!

[casella]

Ping :)

[adeas31]

This was not a regression. We didn't check DynamicSelect on components that come from extends class.

[dietmarw]

@adeas31 Yes you are right. The non-extended dynamicSelect text did actually still work. But with #9437 this is even better now.

[dietmarw]

* [ ]  Support for functions
* [ ]  support for points
* [ ]  support visible (possible different issue)

What about those? Are those also fixed for 1.20.0 now?

[adeas31]

No, they will be fixed with the new instance based api approach.

[casella]

@dietmarw see #8425.

[bilderbuchi]

Reopen if you still have issues with DynamicSelect.

I have to admit I'm confused about which parts of DynamicSelect are supposed to work now. Is there an overview of what is currently (1.20.0) expected to work?

I'm currently trying to rotate a Rectangle using DynamicSelect, and it's not moving. All I notice when I'm scrubbing time in the Diagram view is 100s of Simulation warnings about "No result for variable somevariable.active in result file."

Rectangle(origin = {-60, 60}, rotation = DynamicSelect(0, to_deg.y), fillColor = {255, 255, 255}, fillPattern = FillPattern.Backward, extent = {{-5, -120}, {5, 0}})

Also, above I read

We do support it for extent though, which is pretty much the same thing except limited to two points.

but if you check with Modelica.Fluid.Examples.Tanks.ThreeTanks, only the levels numbers are changing when afaict the extent of the blue rectangles should also change with the levels.

[casella]

@bilderbuchi forget about 1.20.0. That still uses the old API, which is currently been replaced by a new, instance-based one, see #8425. Fixing the old API is hopeless, we are no longer going to maintain it.

Please try with the latest nightly and run OMEdit --NAPI=true, that's where the current action is. This is still under development and with several issues, but once we fix the we'll make --NAPI=true by default, hopefully in 1.21.0 already.

[casella]

@bilderbuchi, the new API is expected to support everything, if you find some feature that still doesn't work, please open a ticket about it.

[bilderbuchi]

@bilderbuchi, the new API is expected to support everything, if you find some feature that still doesn't work, please open a ticket about it.

All clear, thanks for clarifying! (For a non-maintainer, it's sometimes hard to keep track/make sense of all these transitions - old/ned frontend, old/new backend, old/new API...)

I'll switch to the nightly + NAPI, then.

edit: I tried with the nightly and NAPI, rotation still does not show. I'll get an MWE together and open an issue.

[casella]

@bilderbuchi I guess we should improve the communication on our roadmap...

For the record

• the transition from old frontend to new frontend took several years, and is now complete: the old frontend is much superior to the old one, which is no longer maintained since 2019, and is the default choice for simulation code generation since version 1.17.0. It is still used for bootstrapping the compiler (only relevant for developers) and for the old GUI API.
• the transition to the new API for OMEdit (which uses the much faster new frontend to instantiate models in order to display them, instead of having OMEdit do it in a poor man's way, relying on the slower old frontend) is currently underway. It will allow to overcome historical limitations of the old API, see Instance-based mechanism to handle parameters, replaceable classes, conditional connectors, and parameter-dependent dialogs #8425, and also be much faster, enabling a better user experience when handling models with many components. The new API is activated optionally with OMEdit --NAPI=true in the 1.21.0-dev nightly builds, because it is still not reliable enough as of today, we hope to get it in a good enough shape for the 1.21.0 release, so it can be activated by default. The functionality is mostly in place and will be complete in one-two months. How much time it takes to iron out all the bugs is difficult to predict. Help in testing it and reporting bugs is very welcome, as it will accelerate the deployment phase.
• the new backend enjoys a more rational structure, compared to the old one that grew organically over 20 yrs, and the possibility to generate array-preserving code, which means much faster build time and also more efficient runtime because of less cache-RAM traffic. This is currently underway, there are a few models that work with it (you can check the testsuite report here), but it's still very far from being production-level. We plan to be able to use it for selected applications (e.g. large power grid models) by the end of 2023. It is still difficult to predict when it could finally replace the old one as default, that would probably take a few more years.
• regarding the runtime, we currently have multiple runtimes. In particular, the C-runtime is the default one, on which most of the development and debugging takes place, and the one that currently achieves better success rate in the library testsuite. We also have a C++ runtime, which has some nice feature made possible by the O-O nature of the language, and that does not rely on dynamic memory management and garbage collection, which is essential for online model-predictive control applications. There are also experimental runtimes, e.g. for embedded systems, but they are not very developed. Eventually we should try to rationalize this part of OMC, there's been some discussion about it, but currently not much resources to actually do it.

[bilderbuchi]

Thanks for the elaboration (although I was not expecting such a detailed reply).

Help in testing it and reporting bugs is very welcome, as it will accelerate the deployment phase.

I'll work in the new API mode, then! 😄

I guess we should improve the communication on our roadmap...

Maybe there's an easily automatable way (Github API) to generate the roadmap from the descriptions of the open milestones, sorted by their due date?
Then you'd only have to update that information in one place, and it auto-updates as the issue milestones evolve (as you are already keeping those current).

[casella]

Thanks for the elaboration (although I was not expecting such a detailed reply).

Now you know exactly what is going on 😄

Maybe there's an easily automatable way (Github API) to generate the roadmap from the descriptions of the open milestones, sorted by their due date? Then you'd only have to update that information in one place, and it auto-updates as the issue milestones evolve (as you are already keeping those current).

Yeah, not really, the tickets are for day-to-day management, what I should write is more on a strategic level.

[bilderbuchi]

Yeah, not really, the tickets are for day-to-day management, what I should write is more on a strategic level.

That's not what I meant. The strategic-level writing happens in the milestone description!
The roadmap is then a list of upcoming milestone names (version numbers), their descriptions, and optionally their planned due date.
Then, as milestones get closed when versions are released, and new milestones are created for issue management, the roadmap can auto-update to be current. This way, there is no duplicated work, the issue milestones get strategic context to assist when assigning issues to them, and there is less chance for roadmaps to grow out of date. 😃

[casella]

Yeah, not really, the tickets are for day-to-day management, what I should write is more on a strategic level.

That's not what I meant. The strategic-level writing happens in the milestone description! The roadmap is then a list of upcoming milestone names (version numbers), their descriptions, and optionally their planned due date. Then, as milestones get closed when versions are released, and new milestones are created for issue management, the roadmap can auto-update to be current. This way, there is no duplicated work, the issue milestones get strategic context to assist when assigning issues to them, and there is less chance for roadmaps to grow out of date. 😃

Since we switched to date-based release, this doesn't work anymore. The milestones we have on GitHub are releases, but they do not correspond to strategic goals, just to release dates (with some adjustments). For example, we have a strategic goal to get the new backend to work well, but I have no clue on which release this will actually happen.