Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Unnecessary restriction related to fmi2Discard #630
PLEASE comment on this - this is very late for inclusion in FMI 2.0.1
Unnecessary restriction related to
Why is the computed subinterval not valid - in other words, why does it require a reset or setstate in order to continue? Perhaps the restriction can be lifted and the computed subinterval made valid?
I'm probably the wrong person to comment on the original intent; however the API is designed to allow an FMU to try to integrate in multiple steps to the next communication point and when it fails to proceed to return as is, without first having to roll back to the original state (which would mean saving it in the first place). Since the co-simulation API in 2.0 does not provide for a way to return "early" in a defined way (i.e. returning the current time to which it integrated), this is the only plausible course of action.
I think the use of the word "successfully" is very slightly misleading in this context, 'cause while it's true, the whole operation was not successful.
@pmai I might misunderstood your comment, but an FMU 2.0 does provide a way to return how much of the step it progressed - fmi2LastSuccessfulTime (related to your comment on returning the current time to which it integrated).
A scenario came to mind that might serve as a use case for lifting the restriction. A scenario consisting of a DE fmu and a CT fmu. The DE fmu is stepped first, as its step sizes varies based on events. The CT fmu probably just have a maximum step size, and can perform any steps smaller than that.
Furthermore, I have come across DE FMUs that are difficult to roll-back due to scheduling of threads and similar.