Second iteration of MSMI format

[eidekrist]

This PR relates to #490, the second iteration of the MSMI format. The work in this PR originates from a mob session where we tried to hash out the new XML format(s) for MSMI. Some of the changes are my own suggestions, so feedback is welcome!

Changes to OspModelDescription.xml:

• The Plug, Socket and Bond concepts are replaced with VariableGroup and VariableGroupContainment.
• A VariableGroup contains no causality information, as its variables can have different causalities. The causality information for each individual variable can be found from the FMUs modelDescription.xml.

Changes to OspSystemStructure.xml:

• ScalarConnection, SumConnection, PlugSocketConnection and BondConnection are no more.
• A new concept, Function, is introduced for performing calculations between connected signals. These are defined within OspSystemStructure.xml with a modelDescription-like interface. A Function has signals (and if necessary parameters) which can be connected to FMU variables.
• A VariableConnection connects two variables. Causality information is found from each variable's simulator's modelDescription.xml.
• A SignalConnection connects an FMU variable and a function signal.
• A VariableGroupConnection connects variable groups to each other in an elementwise fashion.
• A SignalGroupConnection connects a variable group to a function signal group. The realization of this in the execution is not yet implemented.

Question: Should a function's signal be identified with an index rather than a name? As of now this identifier is ignore, but it might be helpful for the future's connection architecture.

[mrindar]

Question: Should a function's signal be identified with an index rather than a name? As of now this identifier is ignore, but it might be helpful for the future's connection architecture.

Where do you mean? In the OspModelDescription.xml (and the configurator GUI) I think the signals should be named. However, we probably have to make an interface for implementing functions, and perhaps that should to a large degree mimic the FMI(?), where the getXXX(...) and setXXX(...) calls uses indexes.

[kyllingstad]

In the OspModelDescription.xml (and the configurator GUI) I think the signals should be named. However, we probably have to make an interface for implementing functions, and perhaps that should to a large degree mimic the FMI(?), where the getXXX(...) and setXXX(...) calls uses indexes.

That interface is the topic of discussion in #464, and it is surprisingly difficult to land something which is simple and concise, yet flexible enough to enable what is being done with the <Function> elements here: defining a connection's I/O set at run time.

Anyway, names are good for humans, numbers are good for computers – especially in performance-critical situations like simulation. So a name-number mapping will almost definitely be needed. In FMI, the mapping is explicit and immutable, because the variables are defined in an XML document which is separate from the code. Whether that is necessary or beneficial for connections depends on the solution of #464, I guess.

[eidekrist]

names are good for humans, numbers are good for computers

We could just add an index to the Signal element to cater for both:

<Signal name="Super readable name" index="3" type="real" causality="input"/>

[eidekrist]

Some more thoughtwork on the potential implications for #464:
In FMI, both the code and the XML document come from the same source, so we can be fairly confident that the metadata matches the code. That will not be the case here. Some external tool (or misguided human) will define a Function in XML, from which we will instantiate a cse::function. Additional validation steps will have to be performed to make sure the cse::function is set up with all the variables it expects, and that they have the expected types and causalities.

We should also validate that all the Function's specified signals are indeed connected to variables.

Some cse::functions will have a strong relationship between a signal and its role in the calculation (for example in a switch). This should also be validated, and while challenging, I don't think it's unachievable.

[kyllingstad]

Just to make sure I understand: "Functions" are the same as "advanced connections" here, right. (And the same as "function units" in ViProMa lingo?)

In FMI, both the code and the XML document come from the same source, so we can be fairly confident that the metadata matches the code. That will not be the case here.

Does that comparison make sense? AFAICT, <Function> elements are somewhat analogous to <Simulator> elements, and not to FMU metadata (<fmiModelDescription>). The analogue to the latter seems like it would be some "connection description" that the contents of a <Function> element would be validated against – exactly what #464 is all about.

Some external tool (or misguided human) will define a Function in XML, from which we will instantiate a cse::function.

Again, to make sure I understand: cse::function would be a new and improved cse::connection, then?

[eidekrist]

Just to make sure I understand: "Functions" are the same as "advanced connections" here, right. (And the same as "function units" in ViProMa lingo?)

Yes, pretty much. The way I used "Function" with capital F is describing the XML element, whereas "cse::function" would be the code counterpart.

In FMI, both the code and the XML document come from the same source, so we can be fairly confident that the metadata matches the code. That will not be the case here.

Does that comparison make sense? AFAICT, <Function> elements are somewhat analogous to <Simulator> elements, and not to FMU metadata (<fmiModelDescription>). The analogue to the latter seems like it would be some "connection description" that the contents of a <Function> element would be validated against – exactly what #464 is all about.

You are right, but where a <Simulator> element points to an FMU, we are currently missing that with the <Function> element.
What we were trying to solve was that the number of inputs/outputs of a function are not necessarily known at compile time. The intent was to solve this by setting up a function's I/O set at run time. The code would then have to validate if this I/O set makes sense for the function.

Some external tool (or misguided human) will define a Function in XML, from which we will instantiate a cse::function.

Again, to make sure I understand: cse::function would be a new and improved cse::connection, then?

Yes, I was thinking that a cse::function would be a simulation entity with its own inputs and outputs - call it an expansion of cse::connection. @mrindar 's ASCII art probably explains it better than my words. The actual connections themselves would then be reduced to very simple transports of values, and the calculations would be performed in the cse::function.

Hope this helps (it's getting late 😄)

[hplatou]

Approved by mamma.