Make M_LS2 compliant with the Modelica Specification

[tobolar]

Currently, M_LS2 widely uses the Dymola's inline commands which made it impossible to use the library within another tools.

With #111 (planed for v2.5.0), all the functions (hopefully) have been redirected to the Dymola's DymolaCommands library. This could give us a chance to follow the similar principle applied to MSL and ModelicaServices, i.e. to "outsource" all vendor-related functionality to a particular library. Or even to add them to ModelicaServices as well.
Mostly functions to handle plots, simulate models and read stuff from mass storage are needed.

We shall discuss the feasibility of this proposal and a necessary effort.

[casella]

First of all, let me state that I publicly disawow this issue's title 😄.

I know something like "Make M_LS2 compliant with the Modelica Specification" sounds way duller, but is probably a more accurate description of the topic. If you want to make it spicier, you may add ", at long last!" 😜

Seriously, from #111 I understand you need the following functions:

• plotArray()
• createPlot()
• simulateModel()
• translateModel()
• simulateMultiExtendedModel()
• readStringMatrix()

These functions serve obviously useful and general purposes, so I would propose that @tobolar makes a PR where he simply adds them to ModelicaServices, with a short textual description of what is their intended semantics, based on what Dymola does with them.

Then, if a tool vendor wants to support M_LS2, they simply need to implement those functions, possibly even starting with empty stubs, in which case the library will not be fully supported, but will at least compile and run, providing most features.

That is what we did a long time ago with the 3D visualization functions of the MultiBody library. As far as OpenModelica is concerned, this would be perfect, and I guess Dymola can be updated in no time, since the implementation is there already.

We just need to check what other tool vendors think, should we invite them here for discussion before we move the issue to the ModelicaStandardLibrary repo?

[casella]

Adding @MartinOtter to the discussion as MAP_LIB deputy leader, @svorkoetter for Maplesoft, @DagBruck for DS, @henrikt-ma for Wolfram, @jespermattsson for Modelon, @gkurzbach for ESI. Feel free to add more people I may have forgotten and may be interested.

[sjoelund]

• readStringMatrix()

I believe that does not belong in ModelicaServices, but rather MSL utilities or in ExternData or something. The other things might not since they sort of assume there is some scripting language. It's a bit separate functionality that should not affect simulation of the examples, right?

Also important is to remove all uses of classDirectory. We already have a ModelicaServices replacement for that. Edit: But note that constants using the string from the loaded resource would not work in FMUs, so avoid that constant for the package and load resources explicitly everywhere instead...

[tobolar]

First of all, let me state that I publicly disawow this issue's title

Just tried to attract the attention. :-) Happy now and changed it.

[tobolar]

Also important is to remove all uses of classDirectory.

This is done in #43 (just for v3.0.0).

[sjoelund]

Also important is to remove all uses of classDirectory.

This is done in #43 (just for v3.0.0).

https://github.com/modelica/Modelica_LinearSystems2/blob/v3.0.0-dev/Modelica_LinearSystems2/package.mo#L6
https://github.com/modelica/Modelica_LinearSystems2/blob/master/Modelica_LinearSystems2/package.mo#L6

There's more locations, too.

[tobolar]

@sjoelund You are right! There have been some issues on development of M_LS2 due to my misunderstanding of the GitHub concept in that time (2017). I will reopen #43 and fix it for the next minor release.

[henrikt-ma]

I'm forwarding this to my colleague @maltelenz.

[tobolar]

To make M_LS2 ready for Modelica Specification will probably need a bit more work. Some functions are constructed in a way that they read a particular input from a particular file - e.g. a matrix called "ABCD" from a file called "dslin.mat".
A discussion of solution of this will need a separate Issue.

[maltelenz]

In addition to the already mentioned functions in #131 (comment) , I see more functions used:

• ExportPlotAsImage
• importInitial
• linearizeModel
• plotParametricCurves
• Dymola_ResolveURI

I don't have experience with this library, so I might need some help with understanding what it does, and how, and why these things are not things that can be part of the Modelica Standard.

How do the various plot things relate to the figure annotations we have in the Modelica standard?

By just reading the Modelica functions, some of these external things seem to be interdependent (the output of one is read in the next). This makes me assume a lot more than a short textual description would be needed for other tools to support them.

It seems very non-standardized to shove a large selection of advanced scripting functionality of one tool into an interface definition in ModelicaServices, and tell all other tools to "deal with it".

My initial reaction is that either of these is true:

1. These functions are so general that all tools should have them and many library developers should want to use them.
2. These functions are mostly specific to this library.

If 1 is true, why should they not become part of the Modelica standard proper?
If 2 is true, why is this library important enough to put its special things in the standard library?

[MartinOtter]

Modelica_LinearSystems2 was developed a long time ago. The main purpose was to make operations on linear systems available in models or scripts. The problem at that time was that records with arrays (the data structure where linear systems are stored), was only supported by Dymola. At that time we also tried to standardize a Modelica script language and M_LS2 was one way in this direction, but this makes no longer sense. Since the script languages used by the Modelica tools have usually support for linear control systems (der(x)=Ax+Bu; transfer function, pole/zero description etc.), this aspect of M_LS2 is not so important anymore, including plotting. However, using such models as controllers in a Modelica model is still very useful. So, to summarize, it might be useful to just copy a subset of M_LS2 in a new library and not include plotting or other very Dymola specific stuff.