Initial drafting of msmi support

[ljamt]

This is the outcome of a mob session before summer where we started exploring features from WP2. About time we make a PR.

CraneController.json CraneController.xml and KnockleBoomCrane.json KnockleBoomCrane.xml specify the configuration of what FMI variables are used to form plugs, sockets and bonds. These files can be treated as extentions to the modelDesrcription.xml and should probably be located in the FMU root.

mapping.json SystemStructure.xml is the proposed cse configuraion file where the connections of plugs and sockets are defined in addition to the rest of the configuration from the SSP. The schema for the SystemStructure is defined in SystemStructure.xsd

The configuration has been extended to include:

• SumConnection configuration as the first example of an instance of a "advanced connection"
• decimationFactor for the sub simulators to configure their time steps

Closes #334 - "Custom configuration format(s) used by CSE" (discussion)
Closes #341 - "Configuration for advanced connections"
Closes #273 - "Configuration support for multiple time step"
Closes #250 - "PoC for wp2 standard"

[markaren]

As you might expect, I would like to see YAML here as well. Sure, we can switch from JSON at a later time, but it will require more work the more JSON is used. Now it is used for this, the Java msmi stuff, scenarios and the new orchestration format. If everyone agree on using JSON, then I can live with that. But am I really the only one that feels it is not suited for this? Perhaps the inability to embed comments is the most prominent example of why another format should be preferred.

[lassebje]

YAML vs json. I think we should focus on ease of parsing for machines and ease of writing for machines. The format should also have good support for a schema language and validation, such as xml schema or json schema. Probably YAML has one as well. It should also be well suited for hierarchies. YAML is probably more rigged towards human readability and "writability". My point is that this format will probably not be edited by humans that much in the end, and in my opinion we could just as well have used XML, since this is the language of FMI elsewhere. Again XML hurts to read and write for humans, but is excellent for computers.

[markaren]

I'm not stuck on YAML either, but I'd love to see a discussion on this. JSON is starting to be used for alot of different things, and I have never seen an open discussion on this. I would also prefer XML over JSON as we already use it for FMI, SSP, DCP and log configuration.

[markaren]

In order to not pollute this PR any further with discussions on which format should be used, I opened a seperate issue for discussion: #334

[ljamt]

cpp_cse_config_parser_test fails in the "linux with docker" build:
Error: parse error - unexpected '}'; expected end of input

Anyone on linux that is able to reproduce?

[eidekrist]

At this moment we look for the extended model description files in the same directory as OspSystemStructure.xml. Should we, in this PR, support bundling of OspModelDescription.xml inside of the FMU file? I would guess this involves moving the parsing code into importer.cpp or the fmu classes, and making the data available through the slave class similar to cse::model_description.

[kyllingstad]

@eidekrist:

Should we, in this PR, support bundling of OspModelDescription.xml inside of the FMU file?

I propose that we leave this for a later PR (after the 0.5.0 release). I think having the XML files outside the FMUs will be the main mode of usage in the use cases for the time being.

[kyllingstad]

The simulator_map type is declared in both cse_config_parser.hpp and ssp_parser.hpp. This causes errors if you include both headers in one translation unit. (Just tried to do this in CSE CLI now.)

[ljamt]

The simulator_map type is declared in both cse_config_parser.hpp and ssp_parser.hpp.
Can we have the simulator_map declared in execution.hpp?

[hplatou]

The simulator_map type is declared in both cse_config_parser.hpp and ssp_parser.hpp.
Can we have the simulator_map declared in execution.hpp?

Either that, or put it in a new cse_config.hpp?

[ljamt]

The simulator_map type is declared in both cse_config_parser.hpp and ssp_parser.hpp.
Can we have the simulator_map declared in execution.hpp?

Either that, or put it in a new cse_config.hpp?

A new cse_config.hpp sounded correct. Other commonalities from the two parsers could be included here.

[hplatou]

Go, go, go!

[eidekrist]

🚀

[markaren]

My comment about putting the (optional) runtime specific entries into a DefaultExperiment tag were never addressed. I'd really like to see something like:

<DefaultExperiment startTime="0.0">
      <Algorithm name="fixedStep" stepSize="1e-4"></Algorithm>
</DefaultExperiment>

Which can be completely ommited btw, rather than:

<StartTime>0.0</StartTime>
<BaseStepSize>1e-4</BaseStepSize>
<Algorithm>fixedStep</Algorithm>

However, the parameters to the Algorithm would be algorithm specific, dunno how that should best be handled. Probably some annotations stuff. Then basically you can have the exact same layout in SSP.

[eidekrist]

I'm not completely opposed to this. Let's continue the discussion in #404.