Clarify whether all constructor functions have to implemented
t-sommer opened this issue · comments
The FMI Spec states that
The FMU must implement all common API functions according to Section 2.2 and the functions for at least one of the interface types.
However the constructor functions (fmi3Instantiate*()) are all listed under "Common Functions" in fmi3Functions.h
/***************************************************
Common Functions
****************************************************/
// ...
/* Creation and destruction of FMU instances */
FMI3_Export fmi3InstantiateModelExchangeTYPE fmi3InstantiateModelExchange;
FMI3_Export fmi3InstantiateCoSimulationTYPE fmi3InstantiateCoSimulation;
FMI3_Export fmi3InstantiateScheduledExecutionTYPE fmi3InstantiateScheduledExecution;even though they technically belong to the respective interface.
See also #CATIA-Systems/FMPy/.
From my point of view, the specification should be more clear here. For example fmi3FreeInstance is not part of Section 2.2 and is not mentioned in one of the interface types. It is mentioned in Section 2.3.
Should we include Section 2.3 into the above sentence, referenced above:
The FMU must implement all common API functions according to Section 2.2 and the functions for at least one of the interface types.
Wasn`t the idea to implement all functions - even if not having useful implementations - to ease implementation of function loading? If that is the case, all these functions should be present and some just return ERROR.
If not, then I agree we should clarify as indicated by @TorstenBlochwitz .
Steering Committee:
Torsten B.: we have a problem ... . In FMI 2.0 we had the requirement to implement every function
Pierre: FMI 3.0 is out ... and is implementable. All the instanciation functions have to be implemented.
Christian, Torsten B: this classification for "common functions" is only in the header file, not a list in sections 2.2. ....
Klaus: we can only relax it ...
Pierre: this is either problematic for the importer or the exporter ....
Andreas: I would explain what we meant it to be ... and treat this as a bug.
Pierre: I would clarify, that only functions that are mentioned in 2.2 and are common have to be implmented. So only one of the instantiate functions
Torsten B: do we have to implement enterEventMode if the FMU does not support event mode?
Torsten S: yes, this is clear.
Torsten S: We should move the interface functions to the specific place
Pierre: or remove the comment "Common Functions"
Klaus: We should add a non-normative text
Pierre: this will only be a clarification.
Torsten B: One argument for implementing all was the static linking
Andreas: I would require to implement all ....
Christian: How would this look like in 3.1 if we define new functions?
Torsten B: We could handle this.
Pierre: If we require all functions, this would be a breaking change of the standard ...
Andreas: Most sane implementations (importers) do not rely on strictness
Pierre: I do not see the reason for breaking the old way.
Torsten S: another argument: the current hand-coded FMU was the first one
Pierre: this was probably the first guy outside this group who implemented this ... and reads the spec ...
Andreas: optional functions necessary?
Pierre: yes! this is clear from the spec.
Andreas: can make sure in the IG that this gets implemented well?
Torsten S: What does "common" mean? E.g. enterEventMode is there in ME and CS, but not in SE ....
Andreas: The "common section" in the spec talks about stuff that is there in more than one.
Torsten B: What about static linking?
Pierre: there are ways to do this. at the most you need three implementations ...
Andreas: this could be explained in the implenters' guide.
Pierre: People who care about static linking know what to do.
TorstenS: Making every function mandatory would ease implementing checking
Klaus: 3 options:
- "Do nothing": Everything is clear,
- Make every thing mandatory
- Create a concrete list for ME, CS, SE
Pierre: the list could be in the header file, this could be clarified.
Poll between 2 and 3?
Pierre: do we need this in 3.0.1? We could work out option 3) and the review it. This a value of itself, even if we would go for 2)
Andreas, Torsten B.: we should not soon release a 3.0.2
Poll between 2 and 3?
2) Andreas, Torsten B., Torsten S, Kaska, Daniel
3) Christian, Pierre, Antoine, Hubertus, Klaus
Abstain: Matthias
--> let's explore option 3, delay FMI 3.0.1
Torsten S.: I will create a PR for 2)
Pierre: I will change PR #1866 for 3)