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

Input Approximation Information from FMU #794

Open
clagms opened this issue Feb 23, 2020 · 4 comments
Open

Input Approximation Information from FMU #794

clagms opened this issue Feb 23, 2020 · 4 comments
Assignees
Milestone

Comments

@clagms
Copy link
Collaborator

@clagms clagms commented Feb 23, 2020

This is an adaptation of #623 (comment).

I propose that FMI 3.0 standardizes the expectations of the input approximation function of the FMU regarding each individual input.

Interpolations and Extrapolations are two different function approximation schemes, and right now there's no way of distinguishing which an FMU implements.

Example:


Consider an FMU A, that implements an input interpolation scheme. When FMU A is at time $t$, and a setReal is called in that FMU A, the FMU A will assume that it is receiving an input that was computed by another FMU B that is already at time $t+H$.
This assumption has to be made because there is no way of knowing the timestamp of an input when a call is made to setReal.
We may argue that the timestamp of a value corresponds to the timestamp of the internal state of the FMU that computed it (although one has to be careful with this definition, and more details are given in the paper cited below).
So, a correct master algorithm will do something like this, every cosim step:

doStep(B, t, H)
getReal(B, y, v)
setReal(A, u, v)
doStep(A, t, H)

An incorrect master algorithm could do something like this, every cosim step:

getReal(B, y, v)
setReal(A, u, v)
doStep(B, t, H)
doStep(A, t, H)

In the above example, the second master algorithm is incorrect because FMU A is assuming that the value it gets is from a "future" timestamp, and will consequently perform an interpolation on it.
So, FMU A only works with Gauss Seidel like master algorithms.

Without explicit timestamps on the inputs, the implementation of a interpolation is different than the implementation of an extrapolation.
The following figure is an attempt at depicting the difference on the inputs that FMU A will give to its internal numerical solver, when used correctly (top) and incorrectly (bottom):
image

I also attach the paper where me and the co-authors hopefully explain this matter a little bit better 😋
cosimcpspaper.pdf

Some people may argue that all FMUs should implement their input approximations expecting an input at time $t$, thereby making correct the second master algorithm in the above example, and incorrect the first master algorithm.
However, note that the gauss seidel implicit algorithm, which is one of the master algorithms proposed by Kübler and Schiehlen's paper (which the FMI claims to be consistent with) is not allowed.

Related to the above is the meaning of the canInterpolateInputs flag.

canInterpolateInputs flag

It's not clear which inputs this flag refers to.
If the FMI is going to supported nested FMUs, then this flag needs to be deleted, and a flag per scalar input needs to be introduced.
As stated in Section 4.1.2., an FMU can be a combination of a hybrid ODE and a sampled data system. In that case, it is not necessarily the case that all continuous inputs are being approximated by the FMU.

Ideally, if we solve the above issue, we solve this ambiguity as well.

PS - This issue has been discussed with, and approved by @CThuleHansen .

@pmai

This comment has been minimized.

Copy link
Collaborator

@pmai pmai commented Feb 23, 2020

Maybe I'm confused here, but when you say

So, a correct master algorithm will do something like this, every cosim step:
doStep(B, t, H)
getReal(B, y, v)
setReal(A, u, v)
doStep(A, t, H)
An incorrect master algorithm could do something like this, every cosim step:
getReal(B, y, v)
setReal(A, u, v)
doStep(B, t, H)
doStep(A, t, H)

This seems to me to be reversed in the context of FMI 1.0/2.0 co-simulation semantics: These more or less actually assume the second set of steps. The former just does not seem valid for FMI co-simulation, more or less precisely for the reasons you then lay out.

In the second set of steps, what you call the timestamp of all exchanged signals is actually very clear: At time t, outputs are read and inputs set for time t, and then a co-simulation step to t + h is performed, leading to the next signal exchange happening at t+h with signals valid for t+h.

This is also made very clear in section 4.1.1 of the FMI 2.0.1 standard:

  1. The slave is able to interrupt the simulation when tc_i is reached.
  2. During the interrupted simulation the slave (and its individual solver) can receive values for inputs u(tc_i) and send values of outputs y(tc_i).

This works perfectly well with the second set of steps, and matches the example master algorithm in the specification.

If you want to do advanced master algorithms, it is the master algorithm that needs to ensure that the values it sets are valid for time tc_i (i.e. the current communication time). It is not able to pass other values to the FMU and hope that the FMU magically inter- or extrapolates them to get the values for tc_i (how would it do that, without knowing the master algorithm and having no information about the time they actually apply to)?

Given that this interpretation of FMI co-simulation makes moot your problem, is consistent with the explicit statements of the spec and the sample master-algorithm in the spec, and seems to be what most implementations actually assume, whereas a different interpretation would lead to lots of problems in the spec, lots of stuff not being defined, I don't see how one would arrive at a different interpretation.

And while section 4.1.2 does indeed state that

Definition (4.1) is consistent with the definition of co-simulation by (Kübler, Schiehlen 2000).

this only applies to definition 4.1, which again clearly bases all calculations of x_i+1 and y_i+1 only on x_i and u_i, never on any other time points.

So it seems to me that you are reading too much into that sentence, and are assuming things which are not actually in the spec.

But again, maybe I'm missing something here, since it seems to me to be very clear...

@clagms

This comment has been minimized.

Copy link
Collaborator Author

@clagms clagms commented Feb 24, 2020

Thank you for this @pmai !

My main concern is that the paper (Kübler, Schiehlen 2000) actually allows for both master algorithms that I proposed earlier (see fig. 6 of that paper).

Moreover, in general, it is reasonable to allow that an FMU can compute its state x_{i+1} from u_{i+1}, as long as not all FMUs in the cosim do so. In our experience, this leads to better co-simulation solutions (more accurate, energy conserving, etc.).

See, for example, the following paper, where the only way to get a good solution was to have adapt some FMUs behave in the manner consistent with the first master algorithm I proposed above:

  • Gomes, Cláudio, Bentley James Oakes, Mehrdad Moradi, Alejandro Torres Gamiz, Juan Carlos Mendo, Stefan Dutre, Joachim Denil, and Hans Vangheluwe. “HintCO - Hint-Based Configuration of Co-Simulations.” In International Conference on Simulation and Modeling Methodologies, Technologies and Applications, 57–68. Prague, Czech Republic, 2019. https://doi.org/10.5220/0007830000570068.

Also see this paper,
Arnold, Martin. “Stability of Sequential Modular Time Integration Methods for Coupled Multibody System Models.” Journal of Computational and Nonlinear Dynamics 5, no. 3 (May 14, 2010): 9. https://doi.org/10.1115/1.4001389.
where Martin describes a sequential method that is much like the first master algorithm I proposed.
See Eq 5a, where you see the first system being integrated, followed by the second, in eq 8. The second system gets the solution for the first in the interval t -> t+H.

In short: if the first master is forbidden by the standard, then please remove references to Kubler and avoid saying that the FMI standard is consistent with that definition.
I'm fine with either support or no support for sequential master algorithms, as long as it is clear where the fmi standard stands.

If you all agree that there should be no support, then I can propose some modifications to the text to hopefully avoid inducing the reader into thinking that the fmi supports this.

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

@chrbertsch chrbertsch commented Feb 24, 2020

I agree with the original comment in #623 (comment) that the notion of "Input interpolation" is misleading.
What we do in fact is an extrapolation form time t_i to t_{i+1} based on the inputs values and its derivative(s) at time t_i.
So I think the name of the flag canInterpolateInputs is misleading.

One could realize an input interpolation using intermediate variable access https://fmi-standard.org/docs/3.0-dev/#state-intermediate-update-mode-co-simulation

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

@chrbertsch chrbertsch commented Mar 1, 2020

I propose to treat this ticket also as master ticket for #603, #622, #623 (comment)

In Berlin in a group with @masoud-najafi, @friedrichatgc , @klausschuch we discussed this; here are my notes:

  • not specifying the input derivative order could create a problem or inefficiency regarding memory allocation in the FMU to store the derivative values (of at the beginning unknown and possibly varying order)
  • the order of passed values to the fmi3SetInputDerivatives for multiple VRs and derivative order >1 is not clearly defined.
  • for interpolation and usage of known input values on the whole interval t_i to t_i+1 one should in FMI 3.0 use Intermediate Variable Access
  • canInterpolateInputs is in fact an extrapolation from point t_i
  • one could and possibly should specify the concrete extrapolation polynomial. Only then could the master really influence the FMU on the whole interval t_i to t_i+1 in a defined way.
    E.g. if the FMU uses 2nd input derivatives, the master must known this
  • it has to be defined if the derivatives set at t_i have to be the real derivatives, or just values that are used in the extraplation polynomial (e.g. to reach a certain value of the inputs at t_i+1)
  • (today almost no-one uses input derivative order higher than 1)
  • ... please extend of correct if I have forgotten something

I do not remember well what we agreed on as next steps:
@friedrichatgc : will you create a PR for this? Shall we discuss this at the next regular design meeting or should we have a separate discussion on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.