pmai
commented
4 years ago Mu.
Or in longer prose: Given your definition of feedthrough, the question whether FMI 2.0/3.0 co-simulation supports it, trivially cannot be answered since the operations you use are not defined in FMI, and you do not specify - in the definition - whether time may elapse during the combination of get_c(set_c()) or not.
There is no way to update (detectibly) the state of a co-simulation FMU without advancing the time, except for initialization mode.
If time passage is allowed (i.e. a call to fmi3DoStep), then trivially FMI co-simulation supports your definition of feedthrough, if not, then it trivially does not (trivially, because h may not be 0, and thus your inability to query the new state).
So I rather think a different question would have to be asked and discussed, e.g. as discussed in #117.
In the rest of this issue, it seems to me you are sometimes reading generic parts of the standard, which apply to model-exchange as well as to co-simulation, only with co-simulation semantics in focus. Similarly the distinction between model feedthrough and its handling at FMU level seems important.
I would support a PR (or multiple PRs) cleaning up the text to clearly state which definition of feedthrough of what (model vs. FMU) is meant in each place, and clarifying whether a statement applies to ME, CS, or both (and/or the new stuff as well).
As an aside: Any changes to the computational model of FMI for co-simulation would require a full-blown FCP.
clagms
nickbattle
andreas-junghanns
chrbertsch
CThuleHansen
KarlWernersson
This issue is an adaptation of https://github.com/modelica/fmi-standard/issues/623#issuecomment-536629923 for fmi3.
First we need a definition of feedthrough.
Given an Co-simulation FMU instance $c$ , the input $u_c$ feeds-through to output $y_c$ when there exist two different values $v_1, v_2$ and FMU state $s_c$, such that $$get_c(set_c(s_c, u_c, v_1), y_c) \neq get_c(set_c(s_c, u_c, v_2), y_c)$$
where:
Here are some properties of the feed-through:
Note that this definition of feed-through is well accepted, and it means the exact same thing as "algebraic dependency between y_c and u_c".
Also note that any ODE that has an output equation of the form: $$\dot{x} = F(x, u)$$ $$y = G(x, u)$$
has feed-through.
This definition is therefore consistent with [Kubler2000], that the fmi3 document claims to be consistent with.
Now let's look at the the FMI text regarding feedthrough.
Right at the beginning, it says:
Setting aside the fact that "direct feedthrough" is redundant with "feedthrough", this induces the reader into thinking that FMI CS supports feedthrough. I would argue that supporting feedthrough is a necessary feature to export Modelica models, in
Then, in the definition of the causality attribute, the words algebraic relationship are used:
Leading the reader to believe that any dependency declared in the ModelStructure, is a feedthrough dependency, and therefore satisfies the definition I put above.
In fact, in the definition of the ModelStructure, it says:
Again, the reader might think that this means there is an algebraic (an instant) dependency between knowns and unknowns.
Thankfully, in the mathematical definition of the FMU for co-simulation, we observe:
Which tells the reader that there is no feedthrough in that model (i.e., the output $y{i+1}$ does not depend algebraically on the input $u{i+1}$).
However, the text immediately after says
which is not true. Equation (4.1) clearly forbids feedthrough, and [Kubler2000] has the equation:
(apologies for the scribbles).
This equation clearly shows the feed-through.
Moreover, later in the standard, there is a remark:
Which makes it clear that feedthrough is not supported, which is also claimed in https://github.com/modelica/fmi-standard/issues/117#issuecomment-430378201.
If indeed the intent is not to support feedthrough in the FMI co-simulation, then I suggest that the parts I've highlighted above be rewritten to avoid giving this idea. On the other hand, feedthrough support can be standardized fairly easily (unless I don't see the full picture) by just re-defining the meaning the of the ModelStructure. If a tool provider does not want to implement feedthrough, he can just specify in the model structure that every output variable is independent of every input variable. If an FMU supports feedthrough, then the burden is on the master algorithm to comply to that restriction. This is also not hard to do (see paper below, or contact me for details).
What should we go for? Feedthrough or no feedthrough. I have a list of sections in the document that are affected by this change.
Some examples:
The FMI provides the necessary features that Modelica®should maybe be restricted to FMI Model Exchange, as I would argue that having feedthrough is an essential feature of Modelica. Even the simplest coupled mechanical models (such as a mass-spring-damper) need feedthrough to be more accurately co-simulated.The FMI provides explicit methods (called by the FMU environment) for setting properties that invalidate cached data. An FMU that chooses to implement a cache may maintain a set of "dirty" flags, hidden from the simulator. A get method, for example to a state, will then either trigger a computation, or return cached data, depending on the value of these flags.is in favor of feedthrough, but needs to be rewritten in case there is no feedthrough.I hope this helps! :)
PS - This issue has been discussed with, and approved by @CThuleHansen .
Refs:
[Kubler2000] - Kübler, R., and W. Schiehlen. 2000. “Two Methods of Simulator Coupling.” Mathematical and Computer Modelling of Dynamical Systems 6 (2): 93–113. https://doi.org/10.1076/1387-3954(200006)6:2;1-M;FT093.
Gomes, Cláudio, Casper Thule, Levi Lucio, Hans Vangheluwe, and Peter Gorm Larsen. 2019. “Generation of Co-Simulation Algorithms Subject to Simulator Contracts.” In 3rd Workshop on Formal Co-Simulation of Cyber-Physical Systems, to be published. Oslo, Norway. Download: cosimcpspaper.pdf