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

Return value for illegal function calls #574

Open
KarlWernersson opened this issue Apr 26, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@KarlWernersson
Copy link
Collaborator

commented Apr 26, 2019

It is usually not well defined what an FMU should return one of its function is called with an illegal argument. With illegal argument i include things like

  • invalid valueReference
  • invalid state call.e.g newDiscreteStates in continoustime mode, setting a fixed parameter after initialization
  • providing a nullState for setFMUstate
  • etc.

Currently an FMU exporter has to either return a warning or an error.
a waring has the risk of getting ignored while an error forces the master to terminate even though it might be able to recover.
I would argue that what behavior you want is more on the master side than on the exported FMU side.

if a master is non interactive during simulation, you would probably want to terminate since you have either programed your master wrong or the exported FMU is wrong and there is little you can do now to fix it.
However if the master is interactive, then a user using it could try do allot of dumb things and it would be sad to force termination instead of giving a proper message, e.g. "illegal call, please do something else"

We could call it
fmi3Illegal

@KarlWernersson KarlWernersson changed the title Return vale for illegal function calls Return value for illegal function calls Apr 26, 2019

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

commented Apr 26, 2019

Regular Design meeting:
Masoud: we need something like this during initialization (e.g. like. This input would lead to a dvision by zero)
Karl: in this specific case, one could use discard. One could use discard for setReal
Klaus: agree. Perhaps we should not mix these two issues: numerical reasons, not allowed function called.
Klaus: Strongly reminds me of DCP discussions ... distinguish between several log / error messages: what can the master expect that the slaves checkes. The master can e.g. know if the call of setting a value went wrong.
Kaska: We need a clear specification how a function call reacts to an error.
Klaus: Look at DCP specfication 3.4.7 , what happens for PDUs (these are essentially function calls)
Kaska: one should get the same error codes for different FMUs in the same error case
Karl: My proposal was more lightweight. Error code are good, but would need a lot of work.
Klaus: in DCP, the focus was on realtime systems. With error codes, more automatization is possible.

Poll (multiple options possible):

  • do nothing (keep it as in FMI 2.0, one could use error or discard)
    ** Antoine, Andreas, Masoud, Kaska
    *define "fmiIllegal" + non standardized human-readable message (could be extended later with error codes)
    ** Karl, Christian B., Masoud, Klaus, Thorsten G.
  • define detailed Error codes for specific cases that we can imagine.
    ** (no one)

Karl will prepare to proposal for the Design meeting.

@pmai

This comment has been minimized.

Copy link
Collaborator

commented Apr 26, 2019

Sorry could again not attend today’s meeting, but might I suggest that instead of adding a new fmi3Illegal or whatever we might want to have fmi3Error be that code, since that is what reasonable people expect an error to be: Something that didn’t work, but nothing gets corrupted or destroyed. If we want to keep the fine-grained distinction between “I’m kaputt” and “everything is beyond repair” (fmi3Error vs fmi3Fatal as defined now), I’d propose something like fmi3Critical or fmi3Serious as the name for what is now fmi3Error.

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

commented May 10, 2019

Regular design webmeeting:
Pierre: We should have something that indicates an illegal call. The is only a small destincion between error and fatal. (in an error one still could continue)
Kaska: what about fmi3warning?
Karl: people do not read errors.
Pierre: Anyway it is just naming ...
Karl: Changing the definition or error between versions is problematic
Klaus: For FMI 3.0 we should not be hesitant in changing things (names, meaning), as we change so much
Masoud: when an FMI signals an error, it stays in this mode. We need something else so that we could continue.

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.