Modelica_Synchronus FMUs not working

[Andreas Heuermann]

As far as I can tell it is not possible to export a Modelica model, that is using features like clocks from Modelic_Synchronus, as an FMU that can be run by a FMU Import Tool.

For example when exporting Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample as a 2.0 FMU and simulating it with OMSimulator the simulation will issue warnings and the results are completely wrong.

setCommandLineOptions("--std=3.5"); getErrorString();

loadModel(Modelica, {"3.2.3"}); getErrorString();
loadModel(Modelica_Synchronous); getErrorString();

buildModelFMU(Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample, version="2.0", fmuType="me"); getErrorString();

system("OMSimulator Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample.fmu"); getErrorString();

andreas@DESKTOP-OSJIVA0:~/workspace/Testitesttest/newTicketClocks$ omc runTests.mos 
true
""
true
""
true
""
"/home/andreas/workspace/Testitesttest/newTicketClocks/Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample.fmu"
""
info:    Set temp directory to    "/home/andreas/workspace/Testitesttest/newTicketClocks"
info:    Set working directory to "/home/andreas/workspace/Testitesttest/newTicketClocks"
info:    Set working directory to "/home/andreas/workspace/Testitesttest/newTicketClocks"
info:    New model "model" with corresponding temp directory "/home/andreas/workspace/Testitesttest/newTicketClocks/model-ew0k961t"
error:   [fmiLogger] module FMI2XML: [Line:105] Unknown element 'Clocks' in XML, skipping
warning: module FMI2XML: [Line:106] Skipping nested XML element 'Clock'
warning: module FMI2XML: [Line:106] Skipping nested XML element 'Inferred'
error:   [fmiLogger] module FMI2XML: Unknown attribute 'clockIndex=1' in XML
info:    model doesn't contain any continuous state
info:    Result file: model_res.mat (bufferSize=10)
info:    Parameter model.root.fmu.periodicClock.solverMethod will not be stored in the result file, because the signal type is not supported
info:    2 warnings
info:    2 errors
0
""

The result of model.sample1.y should be a clocked version of a sine curve.
I have added the modelDescription.xml to this ticket.

Or is it just that I exported the FMU wrong and it is possible? The Cpp should be able to use clocks in FMUs, but it didn't change anything for me when adding simCodeTarget=Cpp.

[Adrian Pop]

This is a bug most likely introduced by the change that added types to the modelDescription. Clocks should not be there. Arun, can you filter out Clocks when you add the types to the xml?

[arunkumar palanisamy]

@adrpo, yes i can filter out the Clocks in the <TypeDefinitions>

[Francesco Casella]

Just for the record, does the model work with the C runtime?

[Andreas Heuermann]

Without FMI? Yes

[Adrian Pop]

In the FMI spec 2.0.2: ​https://github.com/modelica/fmi-standard/releases/download/v2.0.2/FMI-Specification-2.0.2.pdf
you can see that only SimpleTypes are allowed in TypeDefinitions.
I think they will add Clocks in FMI 3.x

    <TypeDefinitions>
      <SimpleType name="Modelica_Synchronous.Types.Resolution">
        <Enumeration>
          <Item name="y" value="1"/>
          <Item name="d" value="2"/>
          <Item name="h" value="3"/>
          <Item name="m" value="4"/>
          <Item name="s" value="5"/>
          <Item name="ms" value="6"/>
          <Item name="us" value="7"/>
          <Item name="ns" value="8"/>
        </Enumeration>
      </SimpleType>
      <Clocks>
        <Clock><Inferred
                intervalCounter="60"
                resolution="1000"
                /></Clock>
      </Clocks>
    </TypeDefinitions>

So for now just filter out Clocks.

[Andreas Heuermann]

Arun did this already, but the results are still completely wrong.

I think we never implemented clocks in FMUs correctly. I'll have a look at how we do it in the C runtime and see how much effort we need to get at least some basic coverage for Modelica_Synchronus FMUs.

[arunkumar palanisamy]

@adrpo according to FMI-Specification-2.0.2, A scalar variable can contain only following attributes

<scalarVariable
   name = ,
   description =,
   valueReference =,
   variability = ,
   causality =,
   initial =,
   canHandleMultipleSetPerTimeInstant />

But we are exporting clockIndex and previous attribute in scalarVariable and this should also be filtered

[arunkumar palanisamy]

this PR ​https://github.com/OpenModelica/OpenModelica/pull/7139, should filter the clocks
in modeldescription.xml

[Francesco Casella]

Replying to AnHeuermann:

I think we never implemented clocks in FMUs correctly. I'll have a look at how we do it in the C runtime and see how much effort we need to get at least some basic coverage for Modelica_Synchronus FMUs.

Is there any reason to do that differently?

[Andreas Heuermann]

Not really, but I didn't check the implementation yet.
But as long we don't use any fancy static or dynamic libraries I don't see that much of a problem. After all the C FMUs and "normal" C models are nearly identical.

[Andreas Heuermann]

Okay, I have added synchronous features to ME C FMUs and it seems that the simulation of Modelica_Synchronous.Examples.Elementary.ClockSignals.SubSample is correct. I might trigger to much events (that don't do anything), but that can be fixed later.

Now I'm adding the same for CS FMUs and after that I need to add some checks to the testsuite.
We should also test how much of Modelica_Synchronous.Examples we can simulate with FMUs.

[Francesco Casella]

Replying to AnHeuermann:

We should also test how much of Modelica_Synchronous.Examples we can simulate with FMUs.

You can check the ​MSL 4.0.0 master-fmi report, look for models in the Modelica.Clocked.

As of this early morning, all these models are either broken or fail at verification. Help yourself :)

The situation is much better with the regular C runtime, see the ​MSL 4.0.0 master report, although there are some test cases that skip one beat for some reason.

You may also have a quick look at them.

I think this is a big problem for 1.17.0, in the sense that we claim support of MSL 4.0.0, but we don't really deliver on this subpackage. Either there are a few stupid bugs that we can fix ASAP before the release, or we should be very clear in the release notes that Modelica.Clocked is still not supported reliably.

[Andreas Heuermann]

Okay, for ME C FMUs it's looking really good. CS FMUs are a bit fishy, but more or less correct. I'm not sure if it because of OMSimulator that the results are not precise, but it is an improvement for sure.

I'm fairly positive that we can fix many of the failing tests from ​MSL 4.0.0 master-fmi report.

See ​https://github.com/OpenModelica/OpenModelica/pull/7155

[Francesco Casella]

Replying to AnHeuermann:

I'm fairly positive that we can fix many of the failing tests from ​MSL 4.0.0 master-fmi report.

See ​https://github.com/OpenModelica/OpenModelica/pull/7155

OK, let's see how it works out. Do you think you can backport this stuff to 1.17.0 safely if it works fine?

[Andreas Heuermann]

I would not recommend to backport it. I didn't add FMI 1.0 fixes and until now 1.17 would be the last version with FMI 1.0. And for my PR I guess we need to merge ​https://github.com/OpenModelica/OpenModelica/pull/7093 or disable all the FMI 1.0 tests.

[Francesco Casella]

Replying to AnHeuermann:

I would not recommend to backport it. I didn't add FMI 1.0 fixes and until now 1.17 would be the last version with FMI 1.0.

OK, let's keep it for 1.18.0.

[Andreas Heuermann]

Seems a lot of FMUs with clocked are now working:
​https://libraries.openmodelica.org/branches/history/master-fmi/2021-02-20%2003:01:05..2021-02-23%2002:46:27.html

@casella Can you confirm this? I'm not good at reading the reports....

[Francesco Casella]

Oh yes!

Unfortunately, this reports shows the combined effects of 8 separate commits, so it is a bit messy. However, we know that clocked stuff is only found in Modelica 4.0.0, Modelica_trunk (i.e., the current master branch of MSL development) and Modelica_Synchronous, and indeed many Clocked models in there were positively affected, in the sense that the simulation results now match the reference files (hence the transition Simulate -> Verify)

However, if you check, e.g., the specific ​Modelica 4.0.0 report, and scroll down to Modelica.Clocked, you'll see that there are still many cases where the verification fails. If you click on the x/y failed links, you can access interative graphical reports that show you the difference between the reference trajectory and the computed one.

I guess the remaining issues are related to #6363, i.e. some errors are in common between the C and FMI runtimes, maybe because of faulty or incomplete interpretation of the clocked semantics.

For example, compare the result of shiftSample with ​the C runtime and with ​FMI.

I guess you should have a look at that, we really have to have a good implementation of synchronous semantics in 1.18.0, when MSL 4.0.0 will be fully supported.

[Francesco Casella]

Ticket retargeted after milestone closed