Handling of direct feed through for cosimulation

[modelica-trac-importer]

Reported by elmqvist on 4 Dec 2012 22:37 UTC Proposal made during discussions with Edward Lee at Berkeley:

Allow getReal to perform calculations of the outputs based on newly defined inputs without the need to call doStep(). This would be the same semantics concerning direct terms as for Model Exchange.

See further details in attached Powerpoint slides.

This semantics might be put on a capability flag.

---

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

[modelica-trac-importer]

Comment by torstenblochwitz on 9 Jan 2013 16:56 UTC Hilding: Is it necessary to call fmiDoStep to trigger the evaluation of outputs, or is it sufficient to call fmiGetXXX like in Model Exchange? Torsten: fmiDoStep is needed to trigger a computation. -> Clarification of spec. is needed.

Chad: If Co-Sim and Model Exchange do different things, should we use the same function names? I would prefer to use differnt names!

Torsten: Inconsistencies might occure. For monolithic slave it might be hard to implement this feature. Markus: Alg. loops must be solved by repetition of the communication step. Hilding: The intention is to solve the algebraic loops first by iteration of inputs and outputs and repeat the step afterwards. Hilding: Use a capability flag as stated above. If a slave is not able to trigger a computation by fmiGet, it would return fmiDiscard if an input was set and no fmiDoStep was called in between.

Desicion: Define a capability flag and clarify spec.

[modelica-trac-importer]

Modified by rerbacher on 25 Jan 2013 16:54 UTC

[modelica-trac-importer]

Comment by eal on 19 Feb 2013 13:00 UTC Apologies for chiming in late.

I suggest a simple clarification. When fmiDoStep succeeds on an FMU (returns fmiOK), then the FMU advances its "current time" to the end of the integration interval.

Hence, a call to fmiSetReal or fmiGetReal before a call to fmiDoStep, sets and gets inputs and output values at the start of the interval. A call to fmiSetReal or fmiGetReal after a call to fmiDoStep, sets and gets inputs and output values at the end of the interval.

Under this interpretation, fmiGetReal must do computation if the output depends immediately on an input (or alternatively, the computation could be done by fmiSetReal, but I believe this is more awkward).

A further clarification is needed: If the step size is 0.0, then the start and end of the interval are considered to be two distinct times. This is the principle behind superdense time, and it is necessary for properly handling discontinuities. A discontinuous signal has two distinct values at a communication time tc, one value before the zero-step-size fmiDoStep (the left limit), and one value after (the right limit).

If an FMU is monolithic, then all outputs depend immediately on all inputs (inputDependency). I believe this is currently the default if the FMU declares nothing about inputDependency. If all outputs depend immediately on all inputs, then it is required that the master algorithm set all inputs before getting outputs.

Note that this does not in any way interfere with solving algebraic loops. In fact, it helps. During the solving of algebraic loops, fmiDoStep should not be called, because that will advance the execution to a (logically) new communication time point.

Note further that this interpretation raises another potential defect (new ticket needed?). Specifically, there is no mechanism provided in the API for informing an FMU of the values of its inputs at the end of an integration interval prior to a call to fmiDoStep. The fmiSetRealInputDerivatives procedure does not accomplish this for signals that are not continuous. At the point of a discontinuity, the input derivatives are infinite. A consequence is that with the current API, some FMUs are not implementable. In particular, it is not possible to make a ZeroCrossingDetector FMU that correctly handles discontinuous inputs.

Edward Lee, Berkeley

[modelica-trac-importer]

Comment by rerbacher on 19 Feb 2013 18:37 UTC Some additional thoughts after the discussion in the Web meeting today:

My current understanding of fmiSetXxx and fmiGetXxx functions is that they are equivalent to simple memory write and memory read operations on variables of a FMU. I.e. I expected that, at any time they are called (before or after a fmiDoStep call), these functions just do this and nothing more (the function names express this, I think).

If a simple Co-Simulation master algorithm sequence for a FMU is:

fmiSetXxx(); //on inputs fmiDoStep(); fmiGetXxx(); //on outputs

I would expect that outputs are already calculated when reaching the fmiGetXxx lines and just have to be read from the internal FMU variables used to hold them. If the fmiGetXxx calls after fmiDoStep result in FMU computations to be performed again (because of the direct feedthrough issues discussed here), this would have undesired computation time drawbacks (esp. for real-time simulations). Would a FMU be expected to handle this intelligently and not perform or do perform the computations on fmiGetXxx depending on the "calling history" of its API functions? This could overcomplicate the FMU code (and be a further source of computation overhead or simply for FMU implementation errors).

Rafael Erbacher, dSPACE

[modelica-trac-importer]

Comment by eal on 20 Feb 2013 04:00 UTC Yes, these are just variable reads and writes, but it is important what the values mean. If one FMU returns from fmiGetXXX() the value of the output at the start of the integration interval, and another returns the value at the end of the integration interval, then no meaningful cosimulation is achieved.

In computer science, a function is said to be "non strict" if not all inputs need to be known to invoke the function. Hence, I suggest adding a capability flag and clarifying the meaning of fmiSetXXXX and fmiGetXXX as follows:

Clarification:

A call to fmiSetXXXX or fmiGetXXXX before a call to fmiDoStep sets and gets inputs and output values at the start of the integration interval. A call to fmiSetReal or fmiGetReal after a call to fmiDoStep sets and gets inputs and output values at the end of the interval.

Capability flag:

isStrict:

If "true" (the default), then at each communication point, the FMU requires that all inputs be set before any call to fmiGetXXXX to retrieve an output. If "false", then the master algorithm may optionally provide only those inputs on which an output immediately depends before retrieving that output. An output is assumed to immediately depend on all inputs unless an inputDependency is given for that output.

Commentary (not to include in the standard document?):

An FMU that is "monolithic," meaning that is performs all its capabilities in one procedure call, will need to be strict. Whether it performs that functionality in fmiDoStep or in the first call to fmiGetReal after fmiDoStep (or initialization) depends on whether its one procedure call computes the outputs that are an immediate response to the current inputs, or its one procedure updates the values to the end of a time interval. The former is reasonable for an FMU whose one procedure does not need to know the current time nor the time step (e.g., it performs a memoryless function).

Note that this proposal now allows for specification of a Jacobian without risk that the master algorithm will assume that the FMU can be invoked non-monolithically.

Edward Lee

[modelica-trac-importer]

Comment by otter on 24 Feb 2013 20:48 UTC At the last FMI meeting it was decided to not include a "direct feedthrough" handling in FMI 2.0, but to postpone such a feature to a later version. Instead, the respecification has been updated:

There is the additional restriction that it is not allowed to call fmiGetXXX functions after fmiSetXXX functions without an fmiDoStep call in between.

in order to always get the same interpretation.

The reason is that a direct feedthrough handling would result in a big change to the current co-simulation interface. In particular there seems to exist no experience on such a feature in the Co-Simulation community. The difference to ModelExchange is that algebraic loops would only be handled at communication points. Between communication points the slaves integrate without any communication even if there is an algebraic loop. The numerical properties are not clear in such a case. For pure discrete FMUs a "direct feedthrough" handling might make sense. But in such a case the FMU can also be described with FMI for ModelExchange and then the feature of "direct feedthrough" is handled properly.

[modelica-trac-importer]

Comment by eal on 24 Jun 2013 09:48 UTC I believe this is a mistake. This decision will make co-simulation much less useful for discrete systems. It will also make it impossible to implement, for example, a standard PID controller as an FMU (the "P" part requires direct feedthrough). It will also make it very difficult to provide FMUs that support both co-simulation and model exchange because different implementations of fmiGetXXX will be required. Moreover, this constraint is unnecessary. If an FMU declares that all outputs have no direct feed-through dependence on any input, then a master algorithm will not need to call fmiGetXXX after fmiSetXXX without an fmiDoStep in between. Only an FMU that declares direct feed-through will need this order to be reversed.

One possibility would be to change the default assumption about direct feedthrough. If the by default, no output directly depends on any input, then any FMU that says nothing about direct feedthrough can be executed according to this proposed constraint.

[modelica-trac-importer]

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

[APillekeit]

Clocks and Hybrid Co-Simulation FCP allows an iterative approach to handle events at a communication point via allowing in Event Mode:

loop until no more events have to be processed for that time instant (events can also result from output changes in other FMUs in Event Mode, that are inputs to an FMU)
{
fmi3SetXXX() //set variables
fmi3NewDiscreteStates()
fmi3GetXXX() //get variables
}

So value propagations for a time instant between FMUs are possible in my view.

[chrbertsch]

Closing as covered by Hybrid-CoSimulation FCP. Please re-open if you disagree.