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

Define allowed call sequence when terminateSimulation = true #1934

Closed
t-sommer opened this issue Apr 9, 2024 · 3 comments · Fixed by #1941
Closed

Define allowed call sequence when terminateSimulation = true #1934

t-sommer opened this issue Apr 9, 2024 · 3 comments · Fixed by #1941
Assignees

Comments

@t-sommer
Copy link
Collaborator

t-sommer commented Apr 9, 2024

The FMI Specification states for fmi3UpdateDiscreteStates() or fmi3DoStep()

When terminateSimulation = fmi3True, the FMU requests to stop the simulation and the importer must call fmi3Terminate.

However since this is not an error it should be allowed to retrieve the current variables (i.e. call fmi3Get{}())
According to the state machine it is also allowed to call fmi3FreeInstance().

See also modelica/Reference-FMUs#482.

@chrbertsch
Copy link
Collaborator

chrbertsch commented Apr 9, 2024

FMI-Design-Webmeeting:

Torsten: does fmi3Terminate has to be called immediately or can values or internal state be retrieved?
Andreas: Is this not defined in the state machine? It does not state "immediately".
Karl, Torsten: in CS you must not make another step. Not set new values.
Andreas: not trigger internal computation. The model indicates that "this is the end of the time of validity"
Pierre: we should reference the return values of fmi3DoStep (status)
Pierre: for the doStep: we have the "terminateSimulation = fmi3True" and a status return value. We have to define processing expectations.
Torsten S.: for terminateSimulation = fmi3True, the values are still correct.
Otto: if we add "immediately, one can call get-Functions in the Terminate-State
Patrick: You can call what you want in state "Terminated"
Pierre: we should not introduce a "semi terminated state". The easiest way to clarify this would be calling fmi3Terminate immediately.
Patrick: We should stick to the way how the importer treats the stop time.
Pierre: for the stop time we do not spell out, what happens when going beyond it.
Patrick: we should fix it here, and then apply it also to the stop time
Pierre: Stop time is harder due to rounding errors.
Pierre: The whole problem with the "semi terminated state" is an FMI3 problem. We cannot fix this in a FMI 3.1
Andreas: "Terminate" state is a sub-state of "FMU-State-settable".
Pierre: What some people want: call get-functions from the importer after the return of terminateSimulation = fmi3True. But with the proposal of deleting the whole sentences, exporters will create FMUs that are in a state where they will error out. For "Terminate" state the FMU already has an implementation.
Torsten: for FMI2 ME it is the same problem,

Initial Poll:

  • adding "immediately": Pierre, Otto, Karl, Christian B.
  • not advance the time and not set variables: Patrick, Masoud, Peter
  • Remove the whole sentence. Just keep "... it is the wish of the FMU to terminate ...": Karl, Torsten S., Masoud

Pierre: we should write in the implementer's guide to call get-functions only in the terminate state.

@t-sommer
Copy link
Collaborator Author

Another solution would be to do the same as if fmi3Error was returned: the FMU transitions automatically to the Terminated state (see https://fmi-standard.org/docs/3.0.1/#common-state-machine). This would avoid an implicit state but break implementations that call fmi3Terminate() as required by the current text.

@chrbertsch
Copy link
Collaborator

FMI Design Meeting:

Torsten: I discussed this offline with Karl and Christian, they now also prefer option 3.
The first solution would cause problems with existing implementations. I would go on with option 3, #1941
Pierre: this has most implication for us creating Reference FMUs ... I do not care very much ... people in practice did not have problems with this ...
Masoud: Does this change require a change in the state chart?
Torten: no, it legalizes the status quo.

Agreement to go on with option 3

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

Successfully merging a pull request may close this issue.

2 participants