Removing cycles between Modelica and ModelicaServices

[sjoelund]

Closes #3909

[HansOlsson]

It is not clear if this is desired.

[MartinOtter]

This cyclic dependency was introduced to guarantee that MSL and ModelicaServices is "consistent". Maybe this was overdone and if tool vendors think that the cyclic dependency should be removed, this is fine with me.

Please, could tool vendors comment whether they see issues here, if this pull request is accepted.

[sjoelund]

This cyclic dependency was introduced to guarantee that MSL and ModelicaServices is "consistent". Maybe this was overdone and if tool vendors think that the cyclic dependency should be removed, this is fine with me.

For OpenModelica we have now been running a version of ModelicaServices that simply removes the uses Modelica from services. This works fine with Modelica 3 and 4 both using ModelicaServices 4. And users don't need to unload ModelicaServices to change Modelica version, etc.

The consistency is enforced by looking at the conversion noneFromVersion when loading Modelica (if it uses ModelicaServices 3.2.3, loading ModelicaServices 4.0.0 is OK according to the annotations).

The weird part is if you only load ModelicaServices and try to use it (because then it has references to Modelica but no uses-annotation so the tool needs to load an MSL version with compatible uses(ModelicaServices)). But I think that might also be an option.

[MartinOtter]

The weird part is if you only load ModelicaServices and try to use it (because then it has references to Modelica but no uses-annotation so the tool needs to load an MSL version with compatible uses(ModelicaServices)).

Good argument. If this is o.k. for Hans, I agree to remove the cyclic dependency (if there is some consistency issues, other issues will pop up - it is probably just a matter which error message appears).

[HansOlsson]

The weird part is if you only load ModelicaServices and try to use it (because then it has references to Modelica but no uses-annotation so the tool needs to load an MSL version with compatible uses(ModelicaServices)).

Good argument. If this is o.k. for Hans, I agree to remove the cyclic dependency (if there is some consistency issues, other issues will pop up - it is probably just a matter which error message appears).

We allow the same (i.e. MSL 3.2 and 4.0.0 using the same ModelicaServices) - while preserving the "cyclic" dependency; that's why I don't see the need for this PR - as it can be done internally in ModelicaServices.

The main change for us was that variables in ModelicaServices need explicit unit-modifier since SIunits cannot be referenced. Obviously we might do more advanced restructuring that breaks this in the future.

The main benefits of having ModelicaServices depending on Modelica are:

• ModelicaServices can use functions such Modelica.Math.Vectors.length in the implementation
• ModelicaServices interface relies on types such as Modelica.Mechanics.MultiBody.Frames.Orientation; having that in ModelicaServices would be a step backward
• Responsibility - currently MA is responsible for Modelica and tool vendors for ModelicaServices; if the services-interface is moved out of MSL it would mean that tool-vendors were responsible for that - which seems wrong.
• The consistency follows from this; a tool can (and should) modify ModelicaServices - but MSL stays the same.

[hubertus65]

I am cheching wiht my team about their thoughts on this one, stay tuned.

[filip-stenstrom]

Comments from the Modelon compiler team:

Wouldn’t the easiest solution be to just make ModelicaServices a subpackage in MSL instead of a separate library? Then we get rid of the uses-annotations.

We’re not familiar with the history behind why ModelicaServices was separated from MSL, but we assume it was done to make it clear what parts the tool vendor should change, and also to allow the language spec to refer to a small library instead of MSL. However, don’t most tool-vendors provide their own MSL regardless, and not just ModelicaServices? At least we (Modelon) have a number of patches, compile the C code, etc.

The drawbacks would be that you need to maintain ModelicaServices for all versions of MSL that your tool supports, and you couldn’t swap out that library only. In practice we almost never update ModelicaServices, and patching is also a very small effort. It wouldn’t be much different from patching another part of MSL, which is more frequent.

--

Regarding the other discussed options:

Creating more top-level libraries to break dependencies: Preferably not. Same reasons mentioned by others.

Copying code: Preferably not, especially since looking at the PR it’s quite a lot. Not certain about type propagation issues via GUI editing. In general it feels like we’re swapping one issue for another.

Just leave it as-is and let tool vendors handle it: OK until there is a good solution. As others mentioned, tools still need to handle cyclic dependencies (although rare) elsewhere.

Move parts of ModelicaServices to spec: Parts of it should be moved, but it can’t solve the entire problem, since it doesn’t really make sense to move Animation to the language.

[HansOlsson]

Comments from the Modelon compiler team:

Wouldn’t the easiest solution be to just make ModelicaServices a subpackage in MSL instead of a separate library? Then we get rid of the uses-annotations.

I see two problems with that:

• How will that work when developing MSL? Currently you load development MSL with tool-specific ModelicaServices, and they are two different packages making it fairly easy to load them separately (at least manually). Merging would mean that developers of MSL would have to integrate tool-specific ModelicaServices in the development version of MSL - to me that seems messier.
• I will have to check, but I don't think we generally change MSL for Dymola (except adding the check-sum to prevent unintended changes; we could probably do some other magic for that).

[filip-stenstrom]

Comments from the Modelon compiler team:
Wouldn’t the easiest solution be to just make ModelicaServices a subpackage in MSL instead of a separate library? Then we get rid of the uses-annotations.

I see two problems with that:

• How will that work when developing MSL? Currently you load development MSL with tool-specific ModelicaServices, and they are two different packages making it fairly easy to load them separately (at least manually). Merging would mean that developers of MSL would have to integrate tool-specific ModelicaServices in the development version of MSL - to me that seems messier.
• I will have to check, but I don't think we generally change MSL for Dymola (except adding the check-sum to prevent unintended changes; we could probably do some other magic for that).

I think you're right about the first point, we didn't fully consider the MSL development workflow. While it would be possible to handle it as a build step (e.g. copy/link in a tool specific subpackage which is on gitignore), you'd have to repeat that every time you change tool, and probably cause more issues.

We then believe that the best would be to just let tool vendors handle this problem for now.

Also, while it won't immediately solve the problem, it would be good if things that belong to the language spec could be moved there.

[henrikt-ma]

Also, while it won't immediately solve the problem, it would be good if things that belong to the language spec could be moved there.

Indeed. The migration path seems straight-forward: first we add the missing pieces to the language, and then the MSL can start using them as soon as it begins to use a version of the language where these pieces exist. Obvious things we could easily introduce in the language:

• Introduce the exit function next to terminate (shadowing problems can be easily avoided by referring to the built-in function using the fully qualified name .exit).
• Introduce the constants in ModelicaServices.Machine as a language-defined MachineConstants (avoiding the shorter name Machine, which would be more likely to cause conflicts) package similar to Connections.
• Introduce ClockedSolverMethod as a built-in type similar to StateSelect (with the difference of having tool-specific choices-annotation), as a replacement for ModelicaServices.Types.SolverMethod (the name SolverMethod seems to generic at the language level).

For loadResource, there is already the discussion in modelica/ModelicaSpecification#2663 about a new resolveURI function in the language; maybe one shouldn't rush introducing the existing loadResources in the language as long as there is still other content in ModelicaServices.

If the MAP-Lib would like to move in this direction, I could initiate the work by setting up three separate Modelica language PRs (exit, MachineConstants, and ClockedSolverMethod).

[hubertus65]

With respect to this particular PR it seems to me that the broadest consent is to do nothing for this release, and make a ticket to transfer as much as possible to the standard, as Henrik suggested. Agreed?