Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Reported by elmqvist on 4 Dec 2012 19:25 UTC
Introduce two mechanisms for cosimulation for an FMU to influence the choice of step size.
For cosimulation, currently, the only mechanism for controlling a step size is to reject fmiDoStep().
The proposal: Introduce a Tnext mechanism (like in fmiEventUpdate) to fmiDoStep().
If fmiDoStep() provides a Tnext, then the orchestrator should ensure that the FMU is invoked later at time Tnext.
If fmiDoStep() is rejected (returns fmiDiscard) and a Tnext is provided, then the orchestrator should interpret Tnext as providing a suggested step size.
Consider an FMU that implements hysteresis and, given a continuous input, produces an output that is +1 or -1 at all times.
The times of the transitions between output values are not predictable.
Currently, the orchestrator will have to search for a step size that delivers acceptable precision.
Comment by torstenblochwitz on 9 Jan 2013 16:38 UTC
Desicion: Go into this direction. A detailed proposal is needed. Hilding will write it.
Comment by rerbacher on 31 Jan 2013 17:22 UTC
I read the document and it raises some questions related to real-time simulations (using FMUs for Co-Simulation):
a) within a periodic task triggered by a hardware timer event
The real-time Master cannot reasonably tune the next execution time "Tnext" of a FMU depending on these return values (as in description text "... the orchestrator should ensure that the FMU is invoked later at time Tnext ...").
Rafael Erbacher, dSPACE GmbH
Comment by jakesson on 18 Feb 2013 11:04 UTC
Comment by eal on 19 Feb 2013 12:26 UTC
If this returns fmiOK, then *nextEventTime will contain a time tau greater than or equal to the communication point tc in the most recent call to call fmiDoStep that succeeded (returned fmiOK) or the start time if no call to fmiDoStep has occurred. The FMU requests that the next call to fmiDoStep use a step size no greater than tau - tc. Note that this requested step size could be zero. If the procedure returns fmiDiscard, then the FMU has no (known) future event times.
I believe this is better than the proposal in the document FMI_Proposal_TimeEventHandling.doc for two reasons: (1) It decouples taking a step from querying about the next event time, allowing the master algorithm to query all FMUs for this time before invoking fmiDoStep on any of them, and (2) the document has many other things in it (such as time precision) which are probably valuable but are too much to take on at this time FMI 2.0.
The key reason that this is necessary is that a master algorithm has to choose a step size before it can invoke fmiDoStep on any FMU. Ideally, it wants to provide the same step size to all FMUs in a round. But if one FMU rejects a step size (returning fmiDiscard), then there may already be other FMUs that have committed to the proposed step size (they have advanced their internal state). Unless the master algorithm can restore the state of those FMUs to the start of the integration interval (which the FMU may not support), then the execution may now become incorrect. The FMU that rejected the step may produce events that are inputs to the FMUs which have already advanced past the time of the event.
Note that this only solves the problem with predictable events. Events that depend on input signals still cannot be handled.
Edward Lee, Berkeley
Comment by eal on 20 Feb 2013 03:56 UTC
Instead, I propose a modest change to the standard that will fully support predictable breakpoints. The proposal is a new capability flag and procedure:
If "true", then the FMU provides the procedure fmiGetNextEventTime. If "false" (the default), then no such procedure is provided, and the FMU does not provide any guidance in advance of a call to fmiDoStep about what step sizes will be acceptable to the FMU.
If this returns fmiOK, then *nextEventTime will contain a time tau greater than or equal to the communication point tc in the most recent call to call fmiDoStep that succeeded (returned fmiOK) or the start time if no call to fmiDoStep has occurred. The FMU requests that the next call to fmiDoStep be provided with a step size no greater than tau - tc. Note that this requested step size could be zero. If the procedure returns fmiDiscard, then the FMU has no (known) future event times and hence provides no guidance in advance of a call to fmiDoStep about what step sizes will be acceptable to the FMU.
A master algorithm should invoke this procedure at each communication time point after setting all input values using fmiSetXXXX and before invoking fmiDoStep at that communication time point. And when it invokes fmiDoStep, it should provide a step size not greater than tau-tc.
Comment by otter on 11 Oct 2013 11:25 UTC
FMI for CoSimulation shall stay as simple black box interface for continuous-time systems (without external events).
This issue is covered.
The FCP allows the FMU to transport information about the expected next event time via