-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General design for (use of) annotations #2459
Conversation
Anyone who wants to add another possible design or add arguments for or against the different alternatives should feel free to edit this directly in the document on the PR branch. Similarly if you just see the need to clarify something. That way, we get the essence of what we are discussing nicely organized. On the other hand, if there is an argument that you disagree with, please make a comment on that line so that we can have a discussion here before it gets removed or altered too much. |
The main file of the PR is this one: https://github.com/modelica/ModelicaSpecification/blob/MCP/0031-annotations/RationaleMCP/0031/annotations.md |
…g or numeric solving This is a first shot at implementing the outcome of the discussion at the last web meeting.
From my perspective it was as simple as: "Leave it as it is in Modelilca." I see no point in moving things that are well defined in the Modelica language, e.g. constant, parameter,..., but also displayUnit and so on, into newly invented annotations.
is a very striking one we should appreciate and don't reinvent the wheel. |
I have a hard time grasp what the paragraph Class Properties is trying to say. |
What happens in Modelica is that annotations are so full of irrelevant stuff they have to be collapsed when looking at the Modelica code in order to have a chance to see the really important parts, and I believe it will be similar with Flat Modelica. The reason for reformulating is thus to avoid the problem of not seeing the important things that are hidden in collapsed annotations. Expanding the annotations doesn't really help either, as it is totally impractical to find the important parts lurking somewhere in a huge annotation. In other words, hiding important information in annotations is a bad design that will have a bad impact on adoption of Flat Modelica outside the Modelica world. |
Annotations can appear in many places in the grammar. The one we usually think of is the annotation-comment inside the comment of a component-declaration. For this one, there are several places where information can be placed instead of inside the annotation, such as the type-prefix or the modification. What I'm trying to cover with the Class Properties is that annotation-comment of a composition. I wanted to show that hiding important information about a class in the annotation isn't the only option available when designing Flat Modelica. |
Of course nothing prevents us from specifying explicitly what are the relevant annotations in Flat Modelica, and state that all other annotations, which are irrelevant for simulation (e.g. graphical annotations, documentation) must be removed. I think this is totally consistent with the rationale behind Flat Modelica, i.e., to have an intermediate declarative representation of the system for simulation (or other mathematical operations such as linearization, optimization etc.) use only.
This is only true if we start from the premise that we should keep all annotations in Flat Modelica. Which I think is not the right premise. If we remove all the irrelevant annotations such as graphical and documentation, what is left will be a lot more manageable and by definition relevant, so it won't have to be collapsed or hidden at all. I don't think we need to reinvent the wheel, just keep what is relevant and discard everything else |
It is true that we are probably not going to carry annotations for icons, diagrams, or documentation over to Flat Modelica. However, when used as an intermediate representation, I imagine that there can be lots of information for purposes we haven't even thought of yet, that will end up in vendor-specific annotations. Note that any annotation that has a clear role for the user interaction with a simulation, such as Also, thinking of the MCP for figure annotations, it isn't obvious to me that these should be stripped off, as they have to do with what to do with a simulation result. To me, it seems necessary to reserve annotations for information that isn't intended for human reading or writing, and that is allowed to become bulky. |
I think that the cause of the discussion is the too wide scope of FlatModelica. There are obviously conflicts between human writeability and readability and the demand In FlatModelica there are no more classes from the original model except functions. There are also no components and connections and their graphical representation any more. Since there are no more components, and therefore no component-oriented dialogs, it doesn't make sense to keep dialogue annotations. And since there is no semiautomatic possibility to change the structure (redeclaration), we don't need choices anymore. We should narrow our focus to the possibility to use FlatModelica for the actual simulation purposes themselves and not try to catch everything. We should only keep annotations which have effect on the simulation itself. These are special class annotations of functions (they still exist). |
I completely agree with @gkurzbach here. Flat Modelica should be amenable to human inspection, but it won't be used for building models. I can see no use for The only annotations we should retain are what we call "structural annotations" in OMC, i.e., annotations that (may) have an influence on efficient code generation, (which are not that many and can be listed explicitly) and throw away everything else by default. We already do that in our pseudo-Flat Modelica output in OMC and I think it makes lots of sense. |
I agree that it depends on the scope. Based on the discussion regarding final and evaluation of parameters we do not only consider simulating the model exactly as specified, and thus the Dialog annotations can make sense (for easier setting of parameters for the simulation), but as Gerd noted flattening changes this - and one possibility is to only use this for top-level parameters. If we consider dynamic visualization of the model (the DynamicSelect for attributes) then the graphics makes sense in some form. However, if we remove object-oriented stuff it means that the graphics need to be statically transformed a bit (we regularly do that in Dymola and 3D Experience for other reasons |
Conclusions from discussion at web meeting:
Next steps:
|
As agreed in today's webmeeting
When adopting the guidelines according to yesterday's meeting, I realized that there is a possible twist that I didn't think of during the meeting. The idea is to narrow down the allowed annotations depending on context. This could be done either using semantic rules or even in the grammar (the non-recursiveness of classes would make it possible to have separate annotation grammars for each type of class). This would allow for the same sort of error detection as with first class language constructs. For example, (I suppose it would be possible to do this kind of checking of annotations also in full Modelica, but I don't know whether there is actually support for rejecting Modelica models based on irrelevant annotations, and I know that at least SystemModeler doesn't have this kind of check.) |
Because it has to be applied by the front-end during the flattening
I'm not sure if removing Evaluate was the right choice. The reason is that we get multiple ways of evaluating parameters:
|
So your point is that the tool generating flat Modelica may not be able to so and hence pass along the burden to the downstream tool while keeping the annotation?
I don't get this, if you say we shouln't remove Evaluate = true, why not having it should be a problem?
I understand the binding equation of a parameter should have constant or parameter variability. Do I miss something here? |
You are missing the heading for this and that there might be external code, which makes evaluation more complicated, and thus we have three different ways of evaluating function calls, constant-fold before generating flat-modelica, constant-fold in the tool importing flat-modelica and leave in the C-code. |
I suggest we leave it out for now, so that the list only contains the annotations that are obviously needed. Exactly how to deal with things related to evaluation of parameters has a separate item in the roadmap, and if it turns out that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, seems ready for now
I'm not sure if I need to approve this as a reviewer, I couldn't find the button to do so. |
No description provided.