FMU CS 2.0 sometimes drops events when multiple ones occur betweeen adjacent step times

[anatoly.trosinenko@…]

When events occur more frequently than step() is called, they are sometimes dropped (like if internal CS 2.0 run-time not supports dense time, if I remember the term right). On the other hand, when built to ME 2.0 and run with the same FMUChecker-2.0.3 (but with its own run-time, respectively), it works as expected.

How to reproduce

Take the attached TestEvents.mo and TestEvents.mos

TestEvents.mo

model TestEvents
  output Integer counter;
initial equation
  counter = 0;
algorithm
  when sample(0, 0.001) then
    counter := counter + 1;
  end when;
end TestEvents;

TestEvents.mos:

print(buildModelFMU(TestEvents, "2.0", "cs"));

Run

omc TestEvents.mos TestEvents.mo

Now run the produced FMU with FMUChecker (tested with version 2.0.3):

$ path/to/fmuCheck.linux64 -h 0.001 -s 1 -n 10 TestEvents.fmu 
[INFO][FMUCHK] FMI compliance checker Test [FMILibrary: Test] build date: Dec 19 2016
[INFO][FMUCHK] Called with following options:
[INFO][FMUCHK] path/to/fmuCheck.linux64 -h 0.001 -s 1 -n 10 TestEvents.fmu
[INFO][FMUCHK] Will process FMU TestEvents.fmu
[INFO][FMILIB] XML specifies FMI standard version 2.0
[INFO][FMUCHK] Model name: TestEvents
[INFO][FMUCHK] Model GUID: {41cde05e-6d4e-4284-ac3e-8ad83c77f5f8}
[INFO][FMUCHK] Model version: 
[INFO][FMUCHK] FMU kind: CoSimulation
[INFO][FMUCHK] The FMU contains:
0 constants
0 parameters
2 discrete variables
0 continuous variables
0 inputs
1 outputs
1 local variables
0 independent variables
0 calculated parameters
0 real variables
1 integer variables
0 enumeration variables
1 boolean variables
0 string variables

[INFO][FMUCHK] Printing output file header
"time","counter"
[INFO][FMUCHK] Model identifier for CoSimulation: TestEvents
[INFO][FMILIB] Loading 'linux64' binary with 'default' platform types
[INFO][FMUCHK] Version returned from CS FMU:   2.0
[INFO][FMUCHK] Initialized FMU for simulation starting at time 0
0,1
0.1,100
0.2,200
0.3,300
0.4,400
0.5,500
0.6,600
0.7,700
0.8,800
0.9,900
1,1000
[INFO][FMUCHK] Simulation finished successfully at time 1
FMU check summary:
FMU reported:
        0 warning(s) and error(s)
Checker reported:
        0 Warning(s)
        0 Error(s)

This is expected. Now run

$ path/to/fmuCheck.linux64 -h 0.1 -s 1 -n 1
< ... >
0,1
0.1,1
0.2,2
0.3,3
0.4,4
0.5,5
0.6,6
0.7,7
0.9,9
1,10
[INFO][FMUCHK] Simulation finished successfully at time 1
FMU check summary:
FMU reported:
        0 warning(s) and error(s)
Checker reported:
        0 Warning(s)
        0 Error(s)

So now we have only one counter tick per simulation step.

On the other hand, when built to 2.0 ME FMU, its output is always the same (or almost the same), as expected, and is like in the first case.

[anatoly.trosinenko@…]

A trivial patch like this (for the OMCompiler repository) seems to fix this particular test case. I'm not sure on the general case, though. For example, what happens if multiple events occur at the same time that by coincidence is a communication point?..

SimulationRuntime/fmi/export/fmi2/fmu2_model_interface.c

@@ -1320 +1320 @@
   fmi2Real* states_der = (fmi2Real*)functions->allocateMemory(NUMBER_OF_STATES, sizeof(fmi2Real));
   fmi2Real* event_indicators = (fmi2Real*)functions->allocateMemory(NUMBER_OF_EVENT_INDICATORS, sizeof(fmi2Real));
   fmi2Real* event_indicators_prev = (fmi2Real*)functions->allocateMemory(NUMBER_OF_EVENT_INDICATORS, sizeof(fmi2Real));
-  fmi2Real t = comp->fmuData->localData[0]->timeValue;
+  fmi2Real* t = &comp->fmuData->localData[0]->timeValue;
   fmi2Real tNext, tEnd;
   fmi2Boolean enterEventMode = fmi2False, terminateSimulation = fmi2False;
   fmi2EventInfo eventInfo;
@@ -1333 +1333 @@
 
   /* fprintf(stderr, "DoStep %g + %g State: %d\n", currentCommunicationPoint, communicationStepSize, comp->state); */
 
+  while (*t < currentCommunicationPoint + communicationStepSize && *t < tEnd) {
   fmi2EnterEventMode(c);
   fmi2EventIteration(c, &eventInfo);
   fmi2EnterContinuousTimeMode(c);
@@ -1466 +1467 @@
     }
   }
 
+  }
+
   functions->freeMemory(states);
   functions->freeMemory(states_der);
   functions->freeMemory(event_indicators);

[anatoly.trosinenko@…]

Of course, the last command in the reproducer should be path/to/fmuCheck.linux64 -h 0.1 -s 1 -n 10

[Lennart Ochel]

Thanks for the report, I will look into it.

[Lennart Ochel]

​OMCompiler#2795 fixes the event handling and integration of continuous states using the explicit euler method. However, I guess there are more problems with the FMUs. We need to test the implementation much more.