You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FMI 2.0.4 Section 2.2.5 defines the DefaultExperiment element of the XML file as:
The interpretation of stepSize is different for FMI-CS, where it means "preferred communication step size", and for FMI-ME, where it means "Default step size for fixed step integrators". After #1939 it was decided to remove the interpretation for FMI-ME entirely.
FMI 3.0.1 Section 2.4.6 gives the same definition for FMI-CS, while the meaning of stepSize is undefined for the other modes.
Although FMI models are not necessarily generated from Modelica models, it is well understood that semantics of Modelica model simulations should be completely captured by FMI. This is stated explicitly in FMI 2.0.4 Section 1.1:
Expressivity: The FMI provides the necessary features that Modelica®, Simulink® and SIMPACK® models can be transformed to an FMU.
This is not stated explicitly in FMI 3.0.1 (why?) but I understand the rationale is the same, given that many concepts like Stream variables or Clocks are clearly built to mirror their Modelica counterparts. Furthermore, is is well understood that the goal of the Modelica Association is to promote open coordinated standards for system simulation.
Regarding the default experiment settings, Modelica 3.6 defines the experiment annotation in Section 18.4, with the following semantics:
The experiment annotation defines the default start time (StartTime) in [s], the default stop time (StopTime) in [s], the suitable time resolution for the result grid (Interval) in [s], and the default relative integration tolerance (Tolerance) for simulation experiments to be carried out with the model or block at hand. If StartTime is not specified it is assumed to be 0.0.
The relationship between the StartTime, StopTime and Tolerance fields of this annotation and the startTime, stopTime and tolerance attributes of DefaultExperiment is obviously that they are identical. Unfortunately, for some reason there is no explicit counterpart in FMI for the Interval field.
The definition "suitable time resolution for the result grid" is not as rigorous as the definition of communication time step as defined by FMI, but it is obviously indicating the same concept. So, if a Modelica model is exported as a FMU-CS, the stepSize attribute of DefaultExperiment can be given the value of the experiment Interval annotation. Unfortunately, it is not possible to pass this information to an FMU-ME, so it is lost for the importing tool, which could instead use it to re-sample a variable step-size simulation on a regular time grid.
I think this should be fixed, either by adding an interval attribute to DefaultExperiment, or by defining the meaning of stepSize in FMI-ME to be the same of FMI-CS, i.e., the default communication interval.
This is of course a minor issue, but yet I see no reason why this piece of information, provided by Modelica since version 3.3 in 2012, should be lost.
I guess the reason it is missing from the FMI-ME DefaultExperiment is that FMI-ME 1.0 was released in 2010, when the Modelica experiment annotation only had StartTime, StopTime and Tolerance. Then, the definition was carried over to newer versions, while probably nobody in the FMI working group noticed that the Interval field was added to the experiment annotation two years later.
To me, this is obviously a minor oversight that could happily be corrected in the 2.0.5 and 3.0.2 patch releases. If that is not possible, then it should definitely be fixed in 3.1.0.
In #1980, @chrbertsch proposes to add this extra attribute to the layered FMI-LS-REF standard. I think we can definitely do that, but yet that layered standard does not define a default experiment, which what the DefaultExperiment element of the main standard XML does. So I think this issue should (also) be fixed here.
The text was updated successfully, but these errors were encountered:
FMI Design Meeting:
Pierre: it should be more clearly explained what is expected. If it belongs to test setups, it could belong to SSP or FMI-LS-REF.
We just could add a non-normative text
Torsten B.: I would keep the definition of FMI 2.0 (default step size)
Pierre: I would suggest in non-normative text that one could it as a default stepsize in case of a fixed-step solver or as an output interval.
Peter: Can a modelica tool take this as the communication stepsize?
Torsten B, Pierre: Yes, but it is not mandatory:
Poll:
Say that meaning of stepSize for ME FMUs is unspecified
(none)
Add non-normative text that stepSize for ME FMUs could be be used for example as a default stepsize in case of a fixed-step solver or as an output interval.
Christian B., Torsten B., Pierre, Nicolas, Timo, Markus, Jan. Masoud, Otto, Nikolai, Peter
Follow up of the discussion in PR #1980.
FMI 2.0.4 Section 2.2.5 defines the
DefaultExperiment
element of the XML file as:The interpretation of
stepSize
is different for FMI-CS, where it means "preferred communication step size", and for FMI-ME, where it means "Default step size for fixed step integrators". After #1939 it was decided to remove the interpretation for FMI-ME entirely.FMI 3.0.1 Section 2.4.6 gives the same definition for FMI-CS, while the meaning of
stepSize
is undefined for the other modes.Although FMI models are not necessarily generated from Modelica models, it is well understood that semantics of Modelica model simulations should be completely captured by FMI. This is stated explicitly in FMI 2.0.4 Section 1.1:
This is not stated explicitly in FMI 3.0.1 (why?) but I understand the rationale is the same, given that many concepts like Stream variables or Clocks are clearly built to mirror their Modelica counterparts. Furthermore, is is well understood that the goal of the Modelica Association is to promote open coordinated standards for system simulation.
Regarding the default experiment settings, Modelica 3.6 defines the experiment annotation in Section 18.4, with the following semantics:
The relationship between the
StartTime
,StopTime
andTolerance
fields of this annotation and thestartTime
,stopTime
andtolerance
attributes ofDefaultExperiment
is obviously that they are identical. Unfortunately, for some reason there is no explicit counterpart in FMI for theInterval
field.The definition "suitable time resolution for the result grid" is not as rigorous as the definition of communication time step as defined by FMI, but it is obviously indicating the same concept. So, if a Modelica model is exported as a FMU-CS, the
stepSize
attribute of DefaultExperiment can be given the value of the experimentInterval
annotation. Unfortunately, it is not possible to pass this information to an FMU-ME, so it is lost for the importing tool, which could instead use it to re-sample a variable step-size simulation on a regular time grid.I think this should be fixed, either by adding an
interval
attribute toDefaultExperiment
, or by defining the meaning ofstepSize
in FMI-ME to be the same of FMI-CS, i.e., the default communication interval.This is of course a minor issue, but yet I see no reason why this piece of information, provided by Modelica since version 3.3 in 2012, should be lost.
I guess the reason it is missing from the FMI-ME
DefaultExperiment
is that FMI-ME 1.0 was released in 2010, when the Modelica experiment annotation only hadStartTime
,StopTime
andTolerance
. Then, the definition was carried over to newer versions, while probably nobody in the FMI working group noticed that the Interval field was added to the experiment annotation two years later.To me, this is obviously a minor oversight that could happily be corrected in the 2.0.5 and 3.0.2 patch releases. If that is not possible, then it should definitely be fixed in 3.1.0.
In #1980, @chrbertsch proposes to add this extra attribute to the layered FMI-LS-REF standard. I think we can definitely do that, but yet that layered standard does not define a default experiment, which what the DefaultExperiment element of the main standard XML does. So I think this issue should (also) be fixed here.
The text was updated successfully, but these errors were encountered: