Expressions get simplified even if flag noSimplify is used

[Lennart Ochel]

I know the flag noSimplify is a very old one. This could either mean that it is very well tested or that it is long-forgotten and no one cares about it. I can see that is does something in some cases, but it does not what I expect for some simple examples. Please check out the following one:

model foo
  Real a;
  Real b;
equation
  a = sin(time);
  b = 0.3 * a + 0.7 * a;
end foo;

If I instantiate model foo without using the flag noSimplify, I get the expected result:

class foo
  Real a;
  Real b;
equation
  a = sin(time);
  b = a;
end foo;

But, if I run the same with noSimplify enabled, I still get the same result. I would expect that in that case the expressions should remain as they are written in the model.

[Martin Sjölund]

The flag should be called noExpensiveSimplify, not noSimplify.

[Adrian Pop]

I think we should have both. noSimplify (really no simplify) and noExpensiveSimplify (no expensive simplify).

[Martin Sjölund]

The problem is most models require simplification in order to generate correct code.
The suggested flags are bad; we support enumeration flags like +simplify=none|simple|full

[Adrian Pop]

Your proposal sounds good. And we should anyway fix the problems in the Codegen so having +simplify=none would help out with that.

[Martin Sjölund]

No. Codegen should not have to deal with stupid expressions. If you add simplify=none, you should simply expect the code to not compile. There are no ASUB expressions simplified into cref's, for example!

[Adrian Pop]

The Codegen should anyway be able to handle ASUB as not all expressions inside it are crefs.
And I think that's a bug that we generate ASUB for crefs instead of directly crefs.
What I'm saying is that simplify actually hides bugs and that's not very good.

[Lennart Ochel]

I agree, it should be possible to deactivate expression simplifications. I think we should replace noSimplify by an enumeration flag as Martin has proposed.