Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification of handling FMUs with constant step size and final step when rounding errors occur #575

Open
ghorwin opened this issue May 24, 2019 · 6 comments

Comments

Projects
None yet
4 participants
@ghorwin
Copy link

commented May 24, 2019

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?

  1. violate the "constant step size" condition and adjust the final interval to be 0.99...1 (=StopTime)
  2. violate the EndTime condition (and risk an exception/error from within the FMU)

Thanks for clarification on the matter,
Andreas

PS: is there anywhere a clause that prohibits a master to call doStep() outside the StartTime/StopTime interval?

@ghorwin

This comment has been minimized.

Copy link
Author

commented May 24, 2019

(reply from: Jean-Philippe Tavella)

Dear Andreas,

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.

Jean-Philippe Tavella

@ghorwin

This comment has been minimized.

Copy link
Author

commented May 24, 2019

(reply from: Martin Sjölund)
Do you calculate next time as:

time = startTime + i * stepSize

Or:

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 
@ghorwin

This comment has been minimized.

Copy link
Author

commented May 24, 2019

@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 time = startTime + i * stepSize appears to fail when (StopTime - StartTime) is not divisible by StepSize. Also, the rounding issue will remain when stepsize is a truncated fractional value (timeStep = 1/3) with StopTime=3.

So, I guess FMUs must indeed handle these situations nicely without complaining in the last step.

@jbernalr

This comment has been minimized.

Copy link
Contributor

commented May 24, 2019

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?
If the user for instance sets a simulation time from 0 to 10,753 seconds for a 10ms StepSize, a warning should be prompted by the integrator asking if the user desires to round off or to change any of the relevant parameters. I think Simulink + FMI Kit work like this.

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

commented May 24, 2019

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 am not so sure. That is the reason why we give the current communication timestep
Karl: the FMU has to synchronize to time + communication timesteps
Klaus: there are FMUs out that do not do this. The ticket tasks only about the final time. Is there not a problem also for other timesteps?
Karl: in FMI 2.0 it was clarified for the doStep. This issue is not a problem but a quality of implementation. FMUs should deal with small rounding errors. Regarding the endTime: it is not a real violation but dealing with rounding error. In FMI 1 there were many problems with "adding up" time.
Klaus: We should try to clarify this issue in the specification. Could be non-normative text (e.g., good implementation would try to handly rounding error.
Klaus: I could not answer the question above. It depends on the FMU.
Klaus: if the FMU needs a constant timestep. But what happens if due to rounding error after some time, the communication timestep changes a little?
Karl: It is enough to say as in FMI 2 that the FMU has to synchronize.
Klaus: We had some discussion some time ago.
Klaus: the current specification does not tell if the communication timestep might change a little bit.

Klaus: I will check the FMI 2 text if we need something to clarify

@ghorwin

This comment has been minimized.

Copy link
Author

commented Jun 3, 2019

Not sure if this is related, but the FMU

fmus_1.0_cs_linux64_AMESim_14_MIS_cs

from the test suite appears to have a problem related to step sizes. At least, the following output is generated by the FMU:

[slave1:debug] MIS_cs_fmiDoStep called at 0.015000 with step size 0.001000

with simulation time limits in the opt file:

StartTime,0.0
StopTime,0.016

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).

-Andreas

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.