Policy for the treatment of Modelica nonconformances in OMC

[Francesco Casella]

We need to define a policy to handle models which are not 100% conforming to the Modelica specification in OMC. In doing so, we have to strike a balance between conflicting goals:

• promote the full standardization of the language in the Modelica Association
• educate users to only use standard language features when writing code, and to progressively remove non-standard features from their existing code base
• attract users of other Modelica tools by providing feasible migration paths for non-conformant code

The first two goals would suggest that any non-conformance to the spec should generate an error. However, this is probably overkill, and might hamper the migration to OMC by old-time users of other tools having a consolidated code base of models.

My proposal is that any non-conformance to the spec should always at least generate a warning, so that the user is aware that his/her code is not 100% Modelica compliant. I would suggest that these warnings cannot be turned off, so there is an incentive to remove the non-conformances from the code base in the medium term.

We then need to decide which of these non-conformances should actually generate errors and abort the translation. IMO, this should always be the case for those situations where the semantics is unclear or inconsistent, and where we might need to "reverse engineer Dymola" in order to understand how to implement them. Examples: writing a = b where a is an enumeration and b an integer, putting integers in equations involving reals without the appropriate conversion functions, changing final modifiers, multiple inheritance from not exactly equal classes, missing within clause in class declarations, wrong package.order files, etc. On the contrary, other non-conformances like non-standard annotations can be safely ignored, so they should only generate an error by default.

We might then add one flag (I would call it 'strict' or something, since it seems that 'pedantic' is already used with a different meaning) that instead generates an error in all these cases. This can be used for the development of libraries (e.g., the MSL), in order to get a correct automatic reporting of models which are 100% clean. However, this flag should be off by default, in order to avoid harassing end-users.

Last, but not least, is the issue of models with missing initial equations. Although these models can give problems when used across different tools, they are by no means illegal. My suggestion is to always generate warnings in such cases, and introduce a special flag to generate an error in such cases, which should be turned on when checking libraries such as the MSL, and be off by default. I would avoid mixing this thing up with the 'strict' flag, because that concerns language conformance, and this would only generate confusion, as it is already the case in Dymola.

[Martin Sjölund]

Postponed until 1.9.1

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.