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

Rework fmi3Discard mechanism for DoStep #535

Open
pmai opened this Issue Feb 13, 2019 · 2 comments

Comments

Projects
None yet
4 participants
@pmai
Copy link
Collaborator

pmai commented Feb 13, 2019

As discussed in the design meeting on 2019-02-13:

The current definition of fmi3Discard only allows restarting of the calculation if full-fledged fmi3Get/SetFMUState support is present. Since fmi3SetFMUState can already be called in terminated/error state, fmi3Discard does not provide more of a potential mechanism for resuming than fmi3Error (except for the indication of the actual reason for the error).

However it is rather more likely that implementations can more easily support reseting the FMU state to the state when entering the fmi3DoStep on a failed step, than having full fledged fmi3SetFMUState support.

Therefore the definitions should be changed, so that:

  • fmi3DoStep returning fmi3Discard means the FMU has ensured that the state is unchanged from entering the fmi3DoStep call, so the FMU remains in step state, and a new fmi3DoStep call starting from the original time can be called.
  • FMUs that cannot support this must return fmi3Error, which auto-transitions to terminated state, but still allows fmi3SetFMUState to restart the FMU.

To be decided: Add a new fmi3-Return Value to indicate that the failed fmi3DoStep is due to not being able to complete the step, and not some other error (e.g. fmi3StepFailed).

@pmai pmai added this to the FMI3.0 milestone Feb 13, 2019

@APillekeit

This comment has been minimized.

Copy link
Collaborator

APillekeit commented Mar 7, 2019

FMI Design Meeting in Regensburg:
Discussion points:

  • fmi3Discard gets a new meaning: last communication step is rolled back internally by the FMU. The master can call doStep() again from last communication point time.
  • add fmi3StepFailed for the case that the FMU can not roll back internally. The internal time is undefined.

The side effects have to be discussed in more detail.

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

chrbertsch commented Mar 22, 2019

@KarlWernersson : will write down a solution discussed in Regensburg

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.