Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Clarification of handling FMUs with constant step size and final step when rounding errors occur #575
I have a question about the correct handling of CoSim-FMUs that cannot use variable communication step sizes.
Example: StepSize = 0.01 s, StartTime = 0, StopTime = 1
Last communication interval would run due to rounding errors from 0.990000001 to 1.000000001. This, however, gives an exception in an FMU about "time out of range" (obviously when evaluation a parameter time series at t=1.00000001 where the data ends excactly at 1).
What would be the correct/expected behavior (in the sense of cross-checking rules) for a co-simulation master?
Thanks for clarification on the matter,
PS: is there anywhere a clause that prohibits a master to call
(reply from: Jean-Philippe Tavella)
According to my experience, it is possible to violate the EndTime condition, especially with FMUs exported from Dymola. Even when the fmi2SetupExperiment() primitive is used by the Master with the parameter stopTimeDefined set to fmi2True.
I don't think there is anywhere in the standard a clause that prohibits a master to call doStep() outside the StartTime/StopTime interval.
(reply from: Martin Sjölund)
time = startTime + i * stepSize
time = time + stepSize
I usually calculate it as the former to avoid accumulating numerical errors. The following Python code shows why:
>>> i = 0 >>> for j in range(0,100): i = i + 0.01 ... >>> i 1.0000000000000007 >>> 0 + 100.0 * 0.01 1.0
@martin: in my code I use the variant to add stepsize to time (same code for constant and variably spaced intervals).
In any case, the solution of using
So, I guess FMUs must indeed handle these situations nicely without complaining in the last step.
Should't the master needs to be sure before (starting computation) that stepSize and StopTime upon all FMUs are set as neccessary not to violate any of the above mentioned constrains?
Regular Design Webmeeting:
Karl: In the FMI 2 Standard it is defined that the FMU has to synchrinize its time to the time defined by the master.
Klaus: I will check the FMI 2 text if we need something to clarify
Not sure if this is related, but the FMU
from the test suite appears to have a problem related to step sizes. At least, the following output is generated by the FMU:
with simulation time limits in the opt file:
With StepSize = 0.001 the error occurs, with 0.0001 the simulation runs fine to the end. Strange... (seems like an internal error in the FMU, maybe related to a check like t+dt > t_end --> error).