Propagation of start values for inputs to simulation

[Rüdiger Franke]

If the model below is opened and simulated with OMEdit (1.9.1+dev (r21649)), the simulation assigns zero to the input u.

Couldn't the simulation use the start value of -2 instead?

How could one otherwise define values for external inputs?

Note: external inputs are needed because the model shall be exported as FMU.

within ;
model DIC_states "Double Integrator Continuous-time"
  parameter Real p = 1 "gain for input";
  parameter Real y1_start = 1 "start value for first state";
  parameter Real y2_start = 0 "start value for second state";
  input Real u(start = -2);
  output Real y1, y2;
  Real x1, x2;
initial equation
  y1 = y1_start;
  y2 = y2_start;
equation
  der(x1) = p*u;
  der(x2) = x1;
  y1 = x1;
  y2 = x2;
end DIC_states;

[Jan Kokert]

Hi!

(start = -2)

is the initial guess value to solve the "initial value problem" to afterwards run the DAE solver.
If you want to have u = -2 at t=0 you need to specify this as an initial equation:

initial equation
  u = -2;

But in your case this is not possible (initial equation system overdetermined) and I guess this is because u is an input and has a default value of 0 (?).

[Lennart Ochel]

Well, there is no need for initial equations of inputs. They are already known and additional equations would lead to over-determined systems. If there is no input-file specified, I think start values should be used.
I am not sure if OMEdit supports input files. Maybe this should become more user friendly.

[Vitalij Ruge]

There are an example:

https://trac.openmodelica.org/OpenModelica/browser/trunk/testsuite/simulation/modelica/solver/LotkaVolterraWithInput.mos

for external input. Omc take the file externalInput.csv(linear interpolation inside)
Or try simflag: -exInputFile=<name>

Omc take the inputs by sorting and not by name ref.

But it's just a prototype. No idea this would help you with FMU.
Currently I used it only for checking the inputs from optimizer with simulation methode and for initial guesss inside optimization.

[Rüdiger Franke]

Thank you for the hints!

Still I wonder, if not the start values are better suited than a constant zero in the case that nothing else is assigned to the inputs.

In particular the interactive environment OMEdit would benefit from such a feature.

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Rüdiger Franke]

It works with +simCodeTarget=Cpp :-)

[Martin Sjölund]

Moved to new milestone 1.9.4

[Lennart Ochel]

In the meantime this works also for c runtime.

[Rüdiger Franke]

How did you get this result for the C runtime?

I just opened the example DIC_states given in the above description in OMEdit. Simulation with the C runtime results in y2 going on a straight line from 0 to 1, i.e. u is not -2, but 0.

Extending "Tools->Options->Simulation:OMC Flags" with "+simCodeTarget=Cpp", the start value of -2 is used for u and y2 goes from 0 to 0.25 and back to 0.

Yesterday but one I also observed that the C runtime does not use the start value when adding an FMI test, see:
​https://github.com/OpenModelica/OpenModelica-testsuite/commit/449f0a68ac0bf5a2d44bafe7b92a37e8e71f284b

[Lennart Ochel]

I just run this script using c and cpp target:

loadString("
within ;
model DIC_states \"Double Integrator Continuous-time\"
  parameter Real p = 1 \"gain for input\";
  parameter Real y1_start = 1 \"start value for first state\";
  parameter Real y2_start = 0 \"start value for second state\";
  input Real u(start = -2);
  output Real y1, y2;
  Real x1, x2;
initial equation
  y1 = y1_start;
  y2 = y2_start;
equation
  der(x1) = p*u;
  der(x2) = x1;
  y1 = x1;
  y2 = x2;
end DIC_states;
"); getErrorString();

simulate(DIC_states); getErrorString();
val(u, 0.0); getErrorString();
val(der(x1), 0.0); getErrorString();

I get -2 in both cases for u and der(x1).

[Rüdiger Franke]

Then it might be an OMEdit / FMI import issue. Strange that it works with OMEdit and the Cpp runtime?!

[Martin Sjölund]

FMI is not the same thing as the C runtime. It is a separate target.

[Lennart Ochel]

Hmm – now I had a closer look at the simulation result. u is only -2 for initialization. During simulation it is constant 0.

[Rüdiger Franke]

Replying to sjoelund.se:

FMI is not the same thing as the C runtime. It is a separate target.

In fact the FMI 2.0 import of the optimization solver HQP considers the start values for FMUs exported with C or with Cpp the same way (both use the same XML file).

So we have two issues here, affecting the C runtime and FMI import.

[Lennart Ochel]

Using the changes from ​PR204 will initialize the inputs with its start values. Please, can one review the changes?

[Lennart Ochel]

Well, now (71012083adc2359ce27909b0cd9b69ff31a634f6/OMCompiler) it should be fixed for the c runtime.

[Lennart Ochel]

Can we close this ticket or is there still an open fmi issue?

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Ticket retargeted after milestone closed

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

I see this ticket is still open, though I cannot really see the point.

If u is an input, it means it will have to be provided at runtime in some appropriate way (e.g. and input file for batch simulation, or by calling fmi2SetReal. At that point, the initialization should be solved using whatever value is provided, and the start attribute should be totally irrelevant. It is only relevant when the variable is either an unknown of a system of equations to be solved iteratively, or a state variable, but an input is neither one.

If no input is provided, then the universally accepted semantics (though it's not in the specification, I guess) is that the input is identically zero. I don't see why any other value should be used at initialization.

[Rüdiger Franke]

The point is user experience. Modelica supports start values for inputs in a standardized way. Why not exploiting them and instead asking users to write some additional, tool specific input file for the simulator?

The exploitation of start values for inputs works by today with all Modelica tools and runtimes I'm using, including also FMI.

[Francesco Casella]

Do you mean that in absence of futher input (as a file or fmi2SetReal),

input Real u(start = -2);

should actually mean that u = -2 all the time?

That makes sense to me, but is it really written in the Modelica Specification?

[Martin Sjölund]

It's not very well specified, but if you treat it like a state variable with der(u)=0 it would make sense to have it u = -2 all the time (unless you have some external input influencing it)

[jmsanchez]

Functional Mock-up Interface 2.0
July 25, 2014
Page 47 of 126
Near the bottom:

If fmiSetXXX is not called on a variable with causality = ″input″ then the FMU must
use the start value as value of this input.