Cosimulation with events

[modelica-trac-importer]

Reported by elmqvist on 4 Dec 2012 19:25 UTC
Proposal developed during discussions at Berkeley:

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.

Example:

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.

---

Migrated-From: https://trac.fmi-standard.org/ticket/116

[modelica-trac-importer]

Comment by torstenblochwitz on 9 Jan 2013 16:38 UTC
Discusion at FMI meeting:
Hilding: Should we go into this direction or not?
Markus: If fmiDoStep returne with fmiDiscard, the master could call fmiGetRealStatus with the according status flag to retrieve the last successful time.
Chad: Proposal is to prevent discarding a step. Above proposal would be more efficient.
Hilding: Additional status flag would be needed: partiallySucceeded if an eveent occured during the last step.

Desicion: Go into this direction. A detailed proposal is needed. Hilding will write it.

[modelica-trac-importer]

Modified by torstenblochwitz on 24 Jan 2013 13:19 UTC

[modelica-trac-importer]

Modified by rerbacher on 25 Jan 2013 16:52 UTC

[modelica-trac-importer]

Comment by rerbacher on 31 Jan 2013 17:22 UTC
I suppose that this ticket and the document FMI_Proposal_TimeEventHandling.doc attached to the mail "[fmi-design] Minimum proposal for FMI time Event Handling" sent on 05.12.2012 by Torsten Blochwitz coincide.

I read the document and it raises some questions related to real-time simulations (using FMUs for Co-Simulation):

1. What should a real-time Master do with the resolution inquired from a FMU with the fmiGetResolution function proposed on page 4 of the document? The hardware timer device that triggers the timer events for (fixed step) real-time OS tasks also has a hardware specific resolution. Is the Master expected to perform a cross-check of the two values and to error out during initialization in case they are not compatible?

2. Also it is unclear to me what a real-time Master should do with fmiGetIntervalCounter (page 4) and/or the proposed additional return arguments *upcomingTimeEvent and *nextEventTime of the fmiDoStep function (page 9). In a real-time use case the fmiDoStep function is executed either

a) within a periodic task triggered by a hardware timer event
b) within an asynchronous task triggered by an I/O hardware 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

[modelica-trac-importer]

Comment by jakesson on 18 Feb 2013 11:04 UTC
Propagation of events in co-simulation events was discussed at the FMI web meeting on January 24 2012. There is also a draft design that puts forward a means to extend the co-simulation API with event support. The minutes and proposal is found at [source:trunk/Meetings/2012-01-24-Web-FMI-20]

[modelica-trac-importer]

Comment by eal on 19 Feb 2013 12:26 UTC
Apologies for chiming in late on this. I have a concrete and simple proposal. Add the following procedure to the API:

fmiGetNextEventTime(fmiReal *nextEventTime)

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

[modelica-trac-importer]

Comment by anonymous on 19 Feb 2013 15:33 UTC
A further clarification on the above: It seems important that all inputs need to be provided via fmiSetXXXX before fmiGetNextTime is called.

[modelica-trac-importer]

Comment by eal on 20 Feb 2013 03:56 UTC
I propose postponing full resolution of this issue, and in particular postpone resolution of how to deal with unpredictable events. Correct and precise execution of a model with FMUs and unpredictable events will be possible in general if all FMUs in a model implement fmiSetState and fmiGetState, but otherwise there are models that will not be able to be correctly executed. But we don't have consensus on a solution for this (and I'm not sure there is a solution).

Instead, I propose a modest change to the standard that will fully support predictable breakpoints. The proposal is a new capability flag and procedure:

CapabilityFlag:

canProvideNextEventTime:

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.

New procedure:

fmiGetNextEventTime(fmiReal *nextEventTime):

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.

Edward Lee

[modelica-trac-importer]

Comment by torstenblochwitz on 20 Feb 2013 11:37 UTC
According to the poll at the Munich meeting we postpone this feature to a leter FMI version.

[modelica-trac-importer]

Comment by otter on 11 Oct 2013 11:25 UTC
The decision was to introduce a third FMI kind "FMI for HybridCoSimulation". This is ModelExchange at initialization and during events and is CoSimulation between events (with additional features in a new fmiDoStep method for triggering events from doStep). FMI 2.0 has been prepared so that HybridCoSimulation can be introduced with not much effort and backwards compatible in FMI 2.1.

FMI for CoSimulation shall stay as simple black box interface for continuous-time systems (without external events).

[modelica-trac-importer]

Comment by cbertsch on 1 Jun 2018 12:35 UTC
Hybrid-co-simulation group: please check if this is covered.

[APillekeit]

This issue is covered.

The FCP allows the FMU to transport information about the expected next event time via

            fmi3eventInfo->nextEventTimeDefined = FmuInstance->nextEventTimeDefined;
            fmi3eventInfo->nextEventTime = FmuInstance->nextEventTime;

and fmi3NewDiscreteStates()

[chrbertsch]

Clsoing as contained in FCP-007