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

Unnecessary restriction related to fmi2Discard #630

Open
chrbertsch opened this issue Sep 25, 2019 · 4 comments

Comments

@chrbertsch
Copy link
Collaborator

commented Sep 25, 2019

Originally posted by @CThuleHansen in #623 (comment)

PLEASE comment on this - this is very late for inclusion in FMI 2.0.1

Unnecessary restriction related to fmi2Discard: Figure 12 on p. 107 shows that fmi2Discard leads to stepFailed. In order to continue simulation from this point, it is necessary to fmi2reset of fmi2SetFMUState according to table on p. 109. However, it is stated on p. 105: fmi2Discard – if the slave computed successfully only a subinterval of the communication

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?

@chrbertsch

This comment has been minimized.

Copy link
Collaborator Author

commented Sep 27, 2019

@pmai : Could you please comment? Thanks.

@pmai

This comment has been minimized.

Copy link
Collaborator

commented Sep 27, 2019

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.

@CThuleHansen

This comment has been minimized.

Copy link

commented Sep 27, 2019

@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.

@chrbertsch chrbertsch added this to the v2.0.1 milestone Sep 28, 2019
@chrbertsch

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 1, 2019

discussed with @pmai and @TorstenBlochwitz won't fix for 2.0.1: cannot change in a compatible way with 2.0
Check for 3.0

@chrbertsch chrbertsch modified the milestones: v2.0.1, v3.0 Oct 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.