Clarify meaning of DefaultExperiment.stepSize for Model Exchange

[t-sommer]

fixes #1939

[t-sommer]

Proposal by @KarlWernersson:

For Model Exchange stepSize is the preferred step size for fixed step solvers.

[t-sommer]

Poll at the Design Meeting:

• State that it has no meaning for ME: Nikolai, Otto, Peter, Christian W., Mohammed, Karl, Kashka
• "Keep" the old definition from 2.0: Torsten S., Karl, Khoa
• Not say anything: Klaus

[KarlWernersson]

I guess not updated,
Did we decide to go with the poll?

In that case
chachge to
For Model Exchange and scheduled execution, step size do not have a defined meaning.

[casella]

I'm sorry I could not participate to the phone meeting and the poll. I still see an open issue with the taken decision.

Assume that you build some system model in Modelica and simulate it satisfactorily with a variable step-size solver and a certain communication interval. You then make an FMU and ship it to a third party, that will simulate it in its own simulation environment using FMI-ME. If we say that stepSize has no definite meaning, this means that the information about what could be a meaningful default communication interval is lost, and has to be guessed. What's the point of doing that?

We are currently testing OpenModelica's FMI generation by simulating all runnable models in open-source libraries using FMI-ME and FMPy using CVODE, which is a reasonable general-purpose algorithm also suitable for stiff systems. We observed that picking the right communication interval is sometimes crucial for simulation success or failure, so we are currently setting the stepSize attribute to the Interval experiment annotation valuen when generating the FMU, so we can later retrieve it when simulating the FMUs. With this new definition, this will no longer work for FMUs generated by other tools.

Again, what is the advantage of losing this information in this scenario? I only see dis-advantages.

Thanks

[casella]

Of course I would be perfectly fine if another attribute was added to specify the communication interval in FMI-CS mode. If that was the intention of this PR, I'm 100% happy about it.

[chrbertsch]

Assume that you build some system model in Modelica and simulate it satisfactorily with a variable step-size solver and a certain communication interval. You then make an FMU and ship it to a third party, that will simulate it in its own simulation environment using FMI-ME. If we say that stepSize has no definite meaning, this means that the information about what could be a meaningful default communication interval is lost, and has to be guessed. What's the point of doing that?
We are currently testing OpenModelica's FMI generation by simulating all runnable models in open-source libraries using FMI-CS and FMPy. We observed that picking the right communication interval is sometimes crucial for simulation success or failure, so we are currently setting the stepSize attribute to the Interval experiment annotation valuen when generating the FMU, so we can later retrieve it when simulating the FMUs. With this new definition, this will no longer work for FMUs generated by other tools.
Again, what is the advantage of losing this information in this scenario? I only see dis-advantages.

Hi @casella : I do not get your point. Do you talk about ME or CS FMUs? For CS FMUs nothing has changed, the FMI 3.0.2 standard still will tell "stepSize defines the preferred communicationStepSize for Co-Simulation."

[casella]

Sorry, I meant ME where I wrote CS. I just edited my original post.

[chrbertsch]

@casella

Again, what is the advantage of losing this information in this scenario? I only see dis-advantages.

The problem is, that this was never defined.
Is a communication interval even defined in the Modelica language, or is it just a concept that some Modelica tools have)?
In ME FMI this concept is at least not defined.

Perhaps FMI-LS-REF is the right place to clearly define what you want, perhaps add it the "experiment section" https://modelica.github.io/fmi-ls-ref/main/#_experiment_setup
If you agree, please open an issue there https://modelica.github.io/fmi-ls-ref/

[casella]

The problem is, that this was never defined.

True, bu I think it should, see below.

Is a communication interval even defined in the Modelica language

Of course it is. Section 18.4 experiment annotation, Interval is defined as

the suitable time resolution for the result grid (Interval) in [s]

Maybe it's not formally defined as "communication interval" and there is no explicit reference to using dense output to resample the outcome of variable step-size solvers, but I'd say the concept is quite clear.

Perhaps FMI-LS-REF is the right place to clearly define what you want, perhaps add it the "experiment section" https://modelica.github.io/fmi-ls-ref/main/#_experiment_setup If you agree, please open an issue there https://modelica.github.io/fmi-ls-ref/

This could be done, but the intent of my comment is to define a default experiment, not a generic named experiment among others.

I understand that Modelica and FMI are independent standard with different purposes, but I also understand they should be coordinated. Now, the description of the Modelica experiment annotation is:

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.

which I understand is exactly the purpose of the DefaultExperiment FMI tag, i.e., defining a default experiment. I'm sorry for the many repetitions of the "default" word, but that is actually the point of my argument 😃

Why not having the same concepts in the two places? I don't really see the point of having the two standards deliberately differing.

Of course the right thing to do would not to interpret stepSize as Interval for FMI-ME, this actually causes confusion. I would just add an Interval field to the DefaultExperiment tag so we can preserve that information from Modelica models to FMI-MEs.

If you think this is worth discussing, I can open a separate issue for that.

Thanks!

[chrbertsch]

If you think this is worth discussing, I can open a separate issue for that.

@casella : Yes please to so.
The concept of a "time resolution for the result grid" does currently not exist in FMI for ME.
I still think, the right place is a layered standard, and not the core standard.

I would just add an Interval field to the DefaultExperiment tag so we can preserve that information from Modelica models to FMI-MEs

Adding an additional attribute is not possible in a maintenance release FMI 3.0.x, and a minor relesae FMI 3.1 is not scheduled currently.
This is why IMHO the rights short-term solution is a layered standard such as FMI-LS-BUS (https://github.com/modelica/fmi-ls-ref). There you can also ship the original Modelica model, from which the FMU was created, so the connection is obvious. And we can without dependence on the FMI release cycle add as many new arguments to the default experiment (https://modelica.github.io/fmi-ls-ref/main/#_experiment_setup) as we want.