missingInnerMessage - a tool _may_ create the instance

[modelica-trac-importer]

Reported by stefanv on 29 Oct 2012 18:16 UTC Section 17.6 of the specification states:

annotation (missingInnerMessage = "message")

When an outer component of the class does not have a corresponding inner component, the string message may be used as a diagnostic message, and then the tool may also temporarily automatically add the corresponding inner component during translation.

The problem with this is that if a tool may create the component during translation, but need not do so, then a library written to take advantage of this feature will not be portable (because the library could actually rely on this feature for creating such inner components within its own hierarchy, not just at the user-model level).

I'm all in favour of this feature, but either a tool must do it, must not do it, or we need to introduce a separate annotation that forces a tool to do it (e.g. createIfMissing = true).

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/891

[modelica-trac-importer]

Comment by mtiller on 29 Oct 2012 19:02 UTC I am in favor of this annotation. But I feel strongly that we need to continue to abide by the principle that stripping annotations from a model should not affect how it is translated (simulated, yes, translated, no).

As such, I think there should be a prohibition against having tools react to this model. By that same token, I am against having any additional annotations that dictate whether or not such a component is added.

This strict handling of annotations is, in my opinion, essential. Otherwise, we will end up with the language semantics bleeding into annotation specifications.

[modelica-trac-importer]

Comment by jmattsson on 30 Oct 2012 08:35 UTC For that matter, what is the meaning of "temporarily automatically adding" the inner component? Does it mean to perform error checking as if the proper inner component was there? If it does, then I think it is OK, assuming that it must reject the model because of the missing inner component. That would mean that the only difference between following the "may" or not is what error messages are given, not affecting what models are accepted or not.

If my interpretation is correct, then I suggest rewriting the text to make it clearer. If it was not correct, then I think it needs to be changed. Adding the annotation should not make a model that was rejected become correct.

[modelica-trac-importer]

Comment by choeger on 30 Oct 2012 08:45 UTC We already discussed this feature (createIfMissing in #725 .

[modelica-trac-importer]

Comment by stefanv on 30 Oct 2012 12:06 UTC My interpretation of "temporarily automatically adding" is that it is added to the model being flattened, during the flattening. The original source (or in the case of a tool with a graphical interface, diagram) is not modified.

[modelica-trac-importer]

Comment by mtiller on 30 Oct 2012 12:38 UTC But even if the original model is not modified, it is still bad if the flattening is used to compile the model (vs. diagnostics). As such, it should be made clear that any "temporary" adjustments to the model are only for the purposes of diagnostics and should not be for the purposes of "helping" the user turn their incomplete model into a complete one for simulation.

[modelica-trac-importer]

Comment by pharman on 30 Oct 2012 13:23 UTC Replying to [comment:6 mtiller]:

But even if the original model is not modified, it is still bad if the flattening is used to compile the model (vs. diagnostics). As such, it should be made clear that any "temporary" adjustments to the model are only for the purposes of diagnostics and should not be for the purposes of "helping" the user turn their incomplete model into a complete one for simulation.

But the automatic addition of missing inner components is required/expected by existing libraries.

[modelica-trac-importer]

Comment by mtiller on 30 Oct 2012 13:35 UTC Pete, are you advocating for this "automatic addition" functionality as part of a well posed Modelica model? I agree it might currently work this way. But the question is, how should it work (in the future). In my opinion, all tools should have a pedantic mode and such a model should fail under that mode.

[modelica-trac-importer]

Comment by johan on 30 Oct 2012 13:46 UTC We use this behavior in Dymola extensively as it allows us to give system models default properties that only are changed by advanced users. So in case this behavior would be changed, an equivalent functionality has to be established somehow.

[modelica-trac-importer]

Comment by pharman on 30 Oct 2012 13:50 UTC Replying to [comment:8 mtiller]:

Pete, are you advocating for this "automatic addition" functionality as part of a well posed Modelica model? I agree it might currently work this way. But the question is, how should it work (in the future).

We need to document things the way they currently operate, or change the libraries to match the way the language is currently specified.

In the longer term you are quite right that the annotations shouldn't define the translation of a model. It is useful however to be able to test translation of submodels without having to add the inner component to each one.

In my opinion, all tools should have a pedantic mode and such a model should fail under that mode.

A model that doesn't meet the language specification should fail in any tool, else we don't move away from the current situation where users argue that their (invalid) model must be valid because it works in tool X.

[modelica-trac-importer]

Comment by stefanv on 30 Oct 2012 14:05 UTC Personally, I'd be quite happy to state that a tool must create the missing "inner" component,regardless of whether or not there is a missingInnerMessage annotation. It should however give a warning that it's doing so (and use the missing inner message for that warning, if one was provided).

Note that in ticket #549, I pointed out that the content of a particular missing inner message in the Fluid library already stated that the tool would create the missing component (that was fixed by removing that part of the message).

If we do not adopt such a feature, then libraries that, "give system models default properties that only are changed by advanced users", as described above by Johan, are not portable between tools (and are in fact non-compliant).

[modelica-trac-importer]

Comment by hansolsson on 4 Dec 2012 21:06 UTC Language group: Agreed to add it, since libraries rely on this. A discusion was whether it should be added at the top, above the top (in case there is a component with the same name) - or as far down as possible. Conclusion was to just say 'visible to all'.

[modelica-trac-importer]

Comment by dietmarw on 20 Dec 2012 08:06 UTC Are these going to be part of 3.2rev2 or 3.3rev1 or 3.4?

[modelica-trac-importer]

Comment by hansolsson on 27 Feb 2013 15:00 UTC Updated in the specification at Waterloo meeting; now also in other svn-folder.

[modelica-trac-importer]

Comment by hansolsson on 12 Mar 2013 11:52 UTC Reverted change back so that adding it is not part of normative text.

[modelica-trac-importer]

Modified by stefanv on 12 Nov 2015 19:50 UTC

[modelica-trac-importer]

Comment by stefanv on 12 Nov 2015 19:50 UTC We either need to document what we agreed on, or agree on something else.

[modelica-trac-importer]

Comment by hansolsson on 13 Nov 2015 08:24 UTC Ticket #1551 was opened for this issue and has been closed (with the same change); so I believe we can close this ticket as duplicate.

[modelica-trac-importer]

Comment by stefanv on 13 Nov 2015 13:08 UTC Ah yes. Sorry.

[modelica-trac-importer]

Comment by hansolsson on 16 Dec 2015 08:07 UTC As discussed above close as duplicate of #1551