OMSimulator icon indicating copy to clipboard operation
OMSimulator copied to clipboard

Endless loop when FMU returns true for enterEventMode,

Open rruusu opened this issue 1 year ago • 2 comments

Description

When simulating a strictly coupled system with an FMU that sets *enterEventMode = true in a call to fmi2CompletedIntegratorStep, the simulation ends up in an endless loop of event re-evaluation.

This can be seen in debug logs as unexpected event detection when

  • there are no event indicators that have changed sign, or no event indicators at all, and
  • the time for the next event is indicated into the future on the last call to fmi2NewDiscreteStates
debug:   Event detected in FMU "VSD.Root.VSD_level1" at time=0.000001

The result file logs an ever growing number of values for the time step in question.

Steps to reproduce the behavior

Steps:

  • Build a ME FMU that returns true for enterEventMode in a call to fmi2CompletedIntegratorStep.
  • Try to simulate a model containing said FMU in OMSimulator.

Result:

  • OMSimulator produces an unending stream of event evaluations at a single point in time.

Expected behavior

There should not be an endless loop of events.

Version and OS

  • Version: OMSimulator v2.1.2-mingw-notlm-debug
  • OS: Win11, 64-bit

rruusu avatar Oct 14 '24 12:10 rruusu

The cause of this error is fairly evident in the source code of oms::SystemSC::doStep():

src/OMSimulatorLib/SystemSC.cpp#L520:

if (callEventUpdate[i] || zero_crossing_event || (fmus[i]->getEventInfo()->nextEventTimeDefined && time == fmus[i]->getEventInfo()->nextEventTime))

Here, callEventUpdate[i] is true, when the last integrator step completion returned *enterEventMode = true.

At the end of the if-block, the surrounding for-loop is restarted,

      // restart event iteration from the beginning
      i=-1;
      continue;

However, callEventUpdate[i] is never modified until the call to fmi2CompletedIntegratorStep at the end of the step, after the restarted for-loop. This part is never reached and the value of callEventUpdate[i] will remain true, and the surrounding loop over the FMUs is restarted over and over again..

rruusu avatar Oct 14 '24 12:10 rruusu

Is resetting callEventUpdate[i] to false after its first evaluation a sufficient fix?

rruusu avatar Oct 14 '24 12:10 rruusu