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

MaximumCommunicationStep #553

masoud-najafi opened this Issue Mar 11, 2019 · 3 comments


None yet
4 participants
Copy link

masoud-najafi commented Mar 11, 2019

Consider a master/slave co-simulation configuration with several slaves. For the sake of simplicity assume slaves compatible with FMI-2.0. Slaves communicates only with the master at communication steps.
Based on internal states and inputs at communication points, some slaves have the capability to request the mater to get called not later than Tcpi for the next communication point.
In other words a slave may put a limit over the next communication step Hcpi. Based on the different requested Hcpi values, the master may choose min(Hcpi) as the next communication step.

This mechanism is useful in several situations:
--Ensuring the internal stability inside the Slave.

--This may also be used by the slave for efficiently handling the predictable triggered (internal) events or even handling some internal non exposed events that create discontinuity in slave outputs.
In this case it is better to inform the master to choose the next comm step at appropriate time instant.

-- Sometimes there are some important information in the slave output signal that may be ignored by the others or by the master if the communication step size is too big.
Consider for example a slave with a Sine signal output. If the communication step is too big, the signal is not sampled frequently enough and aliasing may happen. Since only the slave have this information, this mechanism can be used by
the slave to limit the communication step-size to allow others capture the signal correctly.

Currently there is no mechanism for this purpose.
Solution 1:
Master ignores this information and chooses a big communication step. If a slave fails, master does a fmi2SetState on the failed slave to roll back to the previous communication point and repeat the step with smaller comm step. But this method quit inefficient and some slave may not support the rollback.

Solution 2:
Assuming that the Slave supports EarlyReturn, the master can ignore this information and let the slave do an earlyReturn at Tcpi. That will become automatically a new communication point between the slave and the master. But the problem is that other slaves may have already missed this communication point and should rollback to this point. The support of EarlyReturn and rollback is necessary for all slaves.

Add fmi3MaximumCommunicationStep enum to the structure

typedef enum{
} fmi3StatusKind;

The type of return value is Float64 with fmi2GetFloat64Status ()
If the return value is 0.0 or negative (default value), that means there is no limit over the communication stepsize.


This comment has been minimized.

Copy link

KarlWernersson commented Mar 11, 2019

Hi would it not be easier to state the max doStepSize in the xml?
If you want to change this dynamicaly i dont see how solution 3 would be better than solution2.
Solution 3 doesn't allow you to preemptive call it, but only as a check after fmiDiscard has returned so you may still have the same problem but less solutions to handle it.
For preemptive call you would need some return value at the end of each doStep returns max next step, alternative a fmi3getNextMaxDoStepSize() but i would prefer return struct.

Is it sufficient with a fixed value in the xml? (default 0 = no limit)


This comment has been minimized.

Copy link

pmai commented Mar 11, 2019

If I understand the proposal correctly, then the idea would be to have something like the nextEventTime mechanism for ME for (Hybrid-)CS: The FMU returns after each successfully completed DoStep optional information about a limit to the next time, indicating beforehand that the master should not try to step past that time limit. For time-based events or other predictable events, this approach can be made to work, and makes sense, since it would allow the master to know about those time limits before stepping all of the FMUs, which would be both simpler, and more efficient than approach 2. (I've changed the maximum step size to an event time in this description, since I think that makes more sense, in terms of mirroring the ME approach).

Of course for many other sources of events, which are not predictable a (potentially long) time before-hand, this does not buy you much, i.e. you'd need the early return mechanism for those.


This comment has been minimized.

Copy link
Collaborator Author

masoud-najafi commented Mar 11, 2019

@KarlWernersson : The value MaximumCommunicationStep is usually variable and may varies as a function of the FMU inputs. So this value cannot be retrieved after DoStep. It should be retrieved after setXXX (inputs) and before calling DoStep().
fmi3getNextMaxDoStepSize() is a good (maybe better) solution, but it is a new API and everyone may not agree to add a new API. fmi2GetFloat64Status () is an already existing API and less intrusive.

@pmai : yes, this is the main idea, but it is not restricted to predictable events. FMU (CS) may not have any event at all and be purely internally continuous, as the use case 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.