Clarify what is supposed to happen if an importer ignores a `fixedInternalStepSize` for co-simulation?

[chrbertsch]

Discussed in #2155

^{Originally posted by elmir-nahodovic April 7, 2026}
Hello,

An FMU may specify the optional co-simulation attribute fixedInternalStepSize, which is given as:

My first question is, what happens if an importer violates the "integer multiple" requirement? The text is non-normative so it suggests to me that I as an importer don't have to abide by it. My example is an FMU that uses a fixed step solver with the following "setup"

Assuming no earlyReturn or eventMode, should I assume that the FMU just does nothing and returns lastSuccessfulTime = t_current

[christoff-buerger]

From an eFMI perspective, (the code of) eFMUs only supports co-simulation satisfying the following requirement:

• The DoStep() is called exactly once for each sampling point according to the fixed stepsize time grid defined by its fixed sampling period; the calls are in sequence.

Any violation of above requirement causes undefined behavior, which in close to all examples I came across so far means wrong simulation results (really ugly; not a warning or simulation abort etc, but wrong results). The reason is that GALEC and production code assume that every time DoStep() is called real-time progressed by the fixed step-size (not perfectly exact -- but good enough with well-defined +/- tolerance: no calls are missed or additional ones added within the sampling period); in other words, a DoStep() call means to go farward in time by the fixed sampling period, and there is no going backwards or jumping ahead over a sampling point. If not, the simulated states (simulation time) and real-time get out of sync. For example, the algorithmic implementation/computation of the update-equations for inline integration often uses the formular x := x + (fixedStepSize * der(x)) that is broken if fixedStepSize is violated.

I am saying this, because my intuition for the fixedInternalStepSize of FMI 3.0 is that it defines exactly this requirement on importers. Of course eFMI and FMI can diverge on the requirements, but my hope is that eFMUs with working production code can be exported as source code FMUs to make them available in the FMI ecosystem. If fixedInternalStepSize does not enforce above requirement, this becomes very complicated -- and I am wondering how one should model the fixed step size szenario of typical embedded hard real-time systems in FMI co-simulation.

[chrbertsch]

Copying discussion from #2155 (comment)

FMI Design Meeting:
Christian, Torsten: The FMU could be "generous" and do something, or raise an error.
Otto: citing from the documentation of doStep. "A fixed-step integrator inside the FMU cannot reach the requested time exactly. fixedInternalStepSize was introduced to counter these effects."
Torsten: Could be communicated otherwise, but not beforehand.
Carsten: I use inline integration .... It would be good to define what the FMU should do
Torsten: You have to deal with comparing floats anyway.