Opened 10 years ago

Last modified 7 years ago

#3139 assigned enhancement

equations do not switch based on param value in if statement

Reported by: arvin84@… Owned by: Adrian Pop
Priority: high Milestone: Future
Component: Frontend Version: trunk
Keywords: Cc:

Description

Hello,

i have a simple model as follows:

model test
  parameter Real b=0;
  Real y;
equation
  if b == 0 then
    y = 1000;
  else
    y = b;
  end if;
end test;

before simulation, first i instantiate the mode and i see that in the flattened model, only the equation regarding to b==0 is considered. i assume that the code generator also considers only this equation because after compilation and running the simulation, changing the value of b in plot window, does not affect the results.

I tried to remove the default value of b and i saw that this time the complete if statements appears in the flattened code after instantiation and therefore compiled after pushing simulation button.

I think the code generator should compile the if statements completely, no matter if the parameter in the if statement has a default value of not, because when you have a model which its dynamics changes regarding to the value of the parameters, and you want to generate an FMU from that, the FMU should also consists all equations for different values of the parameter.

Thanks,
Arvin

Change History (14)

comment:1 by Lennart Ochel, 10 years ago

Component: Code GenerationFrontend
Owner: changed from Lennart Ochel to Adrian Pop
Status: newassigned

This is not a code generation issue, since b get evaluated and the if-equation simplified within the front end.
Adrian, is it intended to evaluate b as structural parameter?

comment:2 by Lennart Ochel, 10 years ago

It seems that b is not marked as structural parameter since it do not appear in the +d=printStructuralParameters-dump. Anyway, the if-equation is evaluated in the front end.

comment:3 by Martin Sjölund, 10 years ago

It is evaluated in the front-end and marked as structural. And then those markings are discarded even though the value is kept as evaluated. I think there is another ticket somewhere around here regarding that issue.

in reply to:  3 comment:4 by arvin84@…, 10 years ago

Replying to sjoelund.se:

It is evaluated in the front-end and marked as structural. And then those markings are discarded even though the value is kept as evaluated. I think there is another ticket somewhere around here regarding that issue.

Do you have any clue how I should fix this problem for all cases? I realized that if I don't give b any value, it will work for this simple case; however, for the following model with a derivative in one of the statements, i receive Template error: Code generation does not support der(pre(lag1.y)).

model test
  model Lag
    import Modelica.Blocks.Types.Init;
    parameter Real k = 1;
    parameter Real T = 1;
    Modelica.Blocks.Interfaces.RealInput u annotation(Placement(visible = true, transformation(origin = {-98, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0), iconTransformation(origin = {-98, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
    Modelica.Blocks.Interfaces.RealOutput y annotation(Placement(visible = true, transformation(origin = {100, -2}, extent = {{-10, -10}, {10, 10}}, rotation = 0), iconTransformation(origin = {100, -2}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  initial equation
    if T <> 0 then
      der(y) = 0;
    end if;
  equation
    if T <> 0 then
      der(y) = (k * u - y) / T;
    else
      y = k * u;
    end if;
  end Lag;
  parameter Real T;
  Lag lag1(T = T) annotation(Placement(visible = true, transformation(origin = {-8, -20}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  Modelica.Blocks.Sources.Step step1(height = 1, startTime = 1) annotation(Placement(visible = true, transformation(origin = {-64, -16}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
equation
  connect(lag1.u, step1.y) annotation(Line(points = {{-20, -20}, {-38, -20}, {-38, -16}, {-54, -16}, {-54, -16}, {-54, -16}}, color = {0, 0, 127}));
end test;


comment:5 by Martin Sjölund, 10 years ago

The problem here is actually that T doesn't have a value, right? omc tries to invert some if-equation in a very bad way.

in reply to:  5 comment:7 by anonymous, 10 years ago

Replying to sjoelund.se:

The problem here is actually that T doesn't have a value, right? omc tries to invert some if-equation in a very bad way.

yes, it seems so. but if i define a value for T, then the problem is that the whole if statement will not be considered in the flattened model. do you have any suggestion to resolve this?

comment:8 by Martin Sjölund, 10 years ago

Milestone: 1.9.21.9.3

Milestone changed to 1.9.3 since 1.9.2 was released.

comment:9 by Martin Sjölund, 9 years ago

Milestone: 1.9.31.9.4

Moved to new milestone 1.9.4

comment:10 by Martin Sjölund, 9 years ago

Milestone: 1.9.41.9.5

Milestone pushed to 1.9.5

comment:11 by Martin Sjölund, 9 years ago

Milestone: 1.9.51.10.0

Milestone renamed

comment:12 by Martin Sjölund, 8 years ago

Milestone: 1.10.01.11.0

Ticket retargeted after milestone closed

comment:13 by Martin Sjölund, 8 years ago

Milestone: 1.11.01.12.0

Milestone moved to 1.12.0 due to 1.11.0 already being released.

comment:14 by Francesco Casella, 7 years ago

Milestone: 1.12.0Future

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.

Note: See TracTickets for help on using tickets.