premature optimization when generating simulation code

[Bill Janssen]

We'd like to be able to build a simulation executable and then run it multiple times, tweaking various parameter values for each run. However, some parameter overrides have no effect. Consider the simulation executable for the attached very abstract model of a vehicle, generated with

  omc +s +i=params.drivetrain params.mo Modelica ModelicaServices
  make -f params.drivetrain.makefile

One can run the model and observe the result:

  % ./params.drivetrain -output=body.s
  time=1,body.s=0.50000000001342925771
  %

It's possible to override some parameters:

  % ./params.drivetrain -output=body.s -override="body.m=2"
  time=1,body.s=0.25000000002465611049
  %

But not all:

  % ./params.drivetrain -output=body.s -override="direction=2"
  time=1,body.s=0.50000000001342925771
  %

This is because some branches of if-equations controlled by parameter expressions are not being included in the generated C code. This appears to be an optimization, and a reasonable default optimization. However, it would be useful to be able to disable it, so that more kinds of parameters could be overridden at simulation time. Optimizations of this type should be enabled by specific optimization flags, and those flags should be added to the set of default optimizations.

In addition, an attempt to override parameters the effect of which has been optimized away should be reported as an error.

[Bill Janssen]

params.mo

[Martin Sjölund]

Reporting errors for trying to override a variable not marked isValueChangeable="true" seems like a fair thing to do.

As for disabling branch selection... This is not an optimization :) It has an effect on the equation count and sorting/matching. Many of the branch selection operations are necessary to perform or the simulation executable will not work (unlike other tools, OpenModelica requires an integer for the number of equations and variables; not a symbolic expression). The only bug is OpenModelica does not know which ones are strictly necessary, so it evaluates as many as it can.

[Bill Janssen]

You'll notice that "direction", the parameter I attempt to change, is indeed marked with isValueChangeable="true". But overriding it still has no effect.

While I agree with your about the effect of branch selection, I still consider this an optimization, with regard to the generation of simulation code. The question here is, what is the purpose of the simulation executable generated by OpenModelica? Is it required to simulate only a single DAE, for instance? Or is that an implementation decision? Is it required at all, in the sense of Modelica? My guess is that it would be advantageous to OpenModelica as a whole to make it as capable as possible, as capable of use in various experimental situations.

Clearly if the condition of the if-equation involves variables, OpenModelica would include code for all the branches; eliminating branches for pseudo-constant conditions (conditions involving only parameters) must therefore be an optimization of some sort.

[tom short]

I've run into this issue, too. Is there a workaround to this? Is there a way to convert parameters to regular variables that can be changed with an override? (I've tried something like that unsuccessfully.)

[Adrian Pop]

Not at the moment.
And I believe any Modelica tool does the same (replacing parameter and constants with their value, whenever it can, to speed up the simulation).

The only way I can think of to do this right now
is to make more executables, one for each different
setting for the structural parameters (array
dimensions, conditions in if branches which have
different number of equations, etc).

[tom short]

I did find a rather kludgey workaround using one parameter and one variable. Then I use a when statement to assign the variable to the parameter after a short time period. The variable is what's used in the if statement instead of the parameter. For janssen's example, that looks something like:

equation
  when time > 0.00001 then
    direction = direction0; // direction is a variable; direction0 is a parameter
  end when;
  if direction == DirectionOfTravel.Forward then
    connect(body.flange_a, forward_engine.flange);
...

[Martin Sjölund]

Except you may not put a connect-equation in an if-equation that cannot be branch-selected on or off :)
If it works, you found a bug...

[tom short]

My model didn't have any connects in an if equation. I didn't try janssen's model.

[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.

[Martin Sjölund]

Moved to new milestone 1.9.4

[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]

The milestone of this ticket has been reassigned to "Future".

If you think the issue is still valid and relevant for you, please select milestone 1.13.0 for back-end, code generation and run-time issues, or 2.0.0 for front-end issues.

If you are aware that the problem is no longer present, please select the milestone corresponding to the version of OMC you used to check that, and set the status to "worksforme".

In both cases, a short informative comment would be welcome.