Unify init.xml files of C and Cpp runtime

[Rüdiger Franke]

The Variables Browser of OMEdit does not show entry fields for models that were translated with the Cpp runtime. It appears that the XML attribute isValueChangeable is missing in the init file.

The question arises, why the C runtime and the Cpp runtime generate different _init.xml files.

[Rüdiger Franke]

cba2c4a/OMCompiler adds isValueChangeable and isDiscrete to the _init.xml file of the Cpp runtime. The question remains, why this separate generator exists at all -- risking problems like the one reported here if the xml generator of the C runtime and OMEdit get further developed.

[Willi Braun]

I'm not sure why we use different code for the same task, maybe niklwors knows more. As far as I see the c-runtime init file has much more information, so probably the cpp runtime could switch to that file.

[Niklas Worschech]

In the cpp- runtime we are using a different index for the valueReference attribute than the c-runtime. The cpp- runtime uses an optimized memory organization for the model variables. The rest should be the same.

[Rüdiger Franke]

The C runtime starts with valueReference 1000; the Cpp runtime with valueReference 0. The C runtime calls the root node fmiModelDescription; the Cpp runtime ModelDescription. There might be more differences.

Wouldn't it be a good idea to not further diverge, but gradually converge the runtimes, i.e. use one and the same _init.xml for both?

Note that FMI2 export uses the same modelDescription.xml already today.

[Rüdiger Franke]

Another difference: the Cpp runtime uses the original variableReference for an aliase, whereas the C runtime introduces a new variableReference for each alias.

[Niklas Worschech]

We can use the same init xml file. We can merge it together with the adaptions for the c and cpp runtime interfaces.

[Rüdiger Franke]

@wbraun: do you have a reason for the offset 1000, for separate variableReferences for aliases and for the root element fmiModelDescription?

[Willi Braun]

Replying to rfranke:

@wbraun: do you have a reason for the offset 1000, for separate variableReferences for aliases and for the root element fmiModelDescription?

No, I think there is no strong reason. I'll take a look.

[Rüdiger Franke]

The generator might call SimCodeUtil.getValueReference. It distinguishes runtimes and use cases with neg aliases in the XML file (FMI1) and without (FMI2) and is already used for the generation of the XML file with a common FMI2 exporter.

Since 8b1f74ec9868827a59de7fd5b07a9ba7e8b01597/OMCompiler also Cpp init.xml and FMI1 export calls this SimCodeUtil.getValueReference.

[Martin Sjölund]

Is the value references even used in the (non-FMU) C runtime? I can only see it used for the profiling html-report.

[Willi Braun]

Replying to sjoelund.se:

Is the value references even used in the (non-FMU) C runtime? I can only see it used for the profiling html-report.

No, we don't need it at all in the c runtime.

[Rüdiger Franke]

Hmm... with the Cpp runtime we saw transposed matrices in OMEdit if the value references were wrong (#4072). This is because the Cpp runtime uses the value references when reading parameter values from the init.xml file.

How does the C runtime assign values from init.xml to model parameters, e.g. upon re-simulate from OMEdit?

[Martin Sjölund]

It reads them in sequential order (it assumes states come first, then derivatives, etc).