Instance-based mechanism to handle parameters, replaceable classes, conditional connectors, and parameter-dependent dialogs #8425
Comments
casella
added
COMP/GUI/OMEdit
|
@AHaumer, @max-privato, @sbaetzing, @niklwors, @dietmarw, @AndreaBartolini, please follow this ticket to see the progress, instead of #2081, which is only a part of the story. |
DesignWhen queried, OMC will return a JSON of the instantiated tree including:
Retrieving a model instance: getModelInstance(Path.To.Model): JSONCalling this API will return the instance tree of the model.
Sending back modifications: setModelInstance(JSON): BooleanCalling this API will apply the modifications from the JSON to the top level Modelica model in the AST.
Evaluating expressions on a model instance: evaluateExpressionOnModelInstance(Expression, Path.To.Model): JSONCalling this API will return the evaluated expression.
GUI <-> OMC communicationThe usual workflow:
NotesSome things to think about:
|
|
There is JSON.mo file that could be used and passed to OMEdit that it could possibly transform to QVariant or work with directly. I would avoid passing large strings |
Yeah, I'm using the existing JSON structures, but dumping it to a string to pass to OMEdit. We'll see how well that works, but dumping the JSON to a string is trivial anyway and something we likely need for OMWebEdit anyway. |
|
Sure, dumping to string is fine for the scripting API. But for OMEdit there's a potentially faster way. And you'd get the same data types if you parse JSON to QVariant so you could just add the shortcut later and prototype this way. |
This is needed in order to draw the complete elements.
We don't need to worry about that part. Since in a normal work flow OMEdit will only ask the JSON once in the beginning and then send back the edited parts to OMC. The only other case when the whole JSON is needed is when user edits the Modelica text manually.
I didn't get that part. Maybe you can elaborate more with some examples. |
Even if we transform to Qt data structures we still have to somehow pass them to OMEdit. |
|
By MetaModelica |
|
I have one comment, based on our past discussion. When editing a model with modifiers, OMC should not only return the actually modified values, but also the default values those parameters would have, in case one deletes the modifed value and wants to see the underlying default. I'm not sure if this feature is already included in @adrpo's proposal. |
For example, have this model: model Test
parameter Boolean a = false;
parameter Real b annotation(Dialog(enable=someModelicaFunction(a));
end Test;OMEdit would get some JSON that could look like: {
"id": "someUniqueNumber",
"name": "Test",
"elements": [
{
"name": "a",
"value": "false"
},
{
"name": "b",
"annotation": "Dialog(enable=someModelicaFunction(a)"
}
]
} How would OMEdit evaluate expression: {
"expression": "someModelicaFunction(a)",
"path": "Test",
"result": "true"
} Of course we could just maybe assign an unique ID for each JSON we send OMC->OMEdit and then refer to that: {
"expression": "someModelicaFunction(a)",
"id": "someUniqueNumber",
"result": "true"
} |
This is not part of my proposal yet. But it should be easy to have. model Test
model M
parameter Real a=10;
end M;
M m(a=20);
end Test;Then one could have a JSON looking like: {
"name": "Test"
"elements": [
{
"name": "M",
"elements": [
{
"name": "m",
"type": "Real",
"value": "10"
}
]
},
{
"name": "m"
"type": "M",
"modifiers": [
{
"name": "a",
"original": "10", // we could also have a modifier chain if there are several levels of modifications [10, 20]
"value": "20",
"each": "none" // to finally support each in the dialogs!
}
]
}
]
} |
What Martin says is that we could write a walker that directly walks MetaModelica structures and gives you a Qt tree in OMEdit. That might be problematic with the instance tree as it has cycles. |
|
If you have a JSON.mo structure with cycles and try to convert to string, you'll have the same problem. |
|
Maybe we should also make an exercise and see how each existing interactive API would be supported with the new one. |
|
I've now opened #8676 with a first draft that implements
And probably a few more I've forgotten. |
|
The issue with BatchPlant_StandardWater is that we don't type deleted components since that they'll just be removed anyway, so we get issues when we try to dump them. We might not actually need to type those since we should never need to evaluate a conditional component, but I'll have to look into that. |
|
But i guess OMEdit doesn't need to see them, so we might as well not dump any of them in the JSON. |
I thought being able to handle conditional connectors was a big part of what we're trying to fix? |
|
@perost With the current version from today OMEdit hangs at startup unfortunately. |
|
I was able to start OMEdit with today's version. However, it is not possible to expand a folder in the library browser because it has been trying for half an hour to exapnd the first subfolder of the |
|
@niklwors we need to check what is going wrong there. In the meantime, maybe you can double-check with other libraries? |
|
@casella The problem occurs with all libraries. |
That's really odd, and also that it was hanging at startup previously. We haven't actually changed anything that should affect that for the last couple of days, and I can't reproduce the issue myself. |
|
For example I opened in the library browser the folder |
|
The logs are not flushed when the process is killed by force. I think it is spinning when @adrpo we really need a job that tests the |
|
I will try to do something about it this week but I'm currently swamped. |
The issue is fixed from what I can see, but now the issue is that it's instead extremely slow and eventually segfaults for me after a couple of minutes. It doesn't look like it actually runs out of memory, but I get a warning from the GC about repeated large allocations that might cause memory leaks or other issues. So I guess the segfault is due to the GC not being able to keep up. I'm not entirely sure how OMEdit works, but I'm assuming that we call Edit: I should perhaps add that it doesn't get stuck but actually progresses through a couple of the components before segfaulting, so it's not an issue with a specific class but rather just a lot of large classes in one package. |
Yes, of course the |
The current mechanism that OMEdit uses for parameter editing and to display component icons in diagrams has OMEdit figure out what are the relevant classes ad inquire their definitions in the used libraries. In this way, local modifications, inheritance, etc. need to be handled ad-hoc by OMEdit, which is clumsy and unnecessarily complicated. See discussion here.
We need to transition to a new mechanism, whereby OMEdit enquires an instance of the model, relying on the new front end to carry out all the complicated work. The NF is very fast, so this is now doable. Additionally, a special "fast instantiation" should be implemented, that only flattens constants, parameters (with their binding equations) and annotations.
This development will be carried out in Q1-Q2 2022.
Doing this will address the root cause of numerous issues that have popped up over the years, and have remained unresolved to date, because fixing the old mechanism is really not an option. These issues are collected here for reference:
While designing this new mechanism, we should also keep in mind that we need to support hierarchical editing of parameters and replaceable stuff in models, a.k.a. "Show component" in Dymola:
This feature also requires to instantiate models and work on the instance to change modifiers
The text was updated successfully, but these errors were encountered: