Removal of duplicated initial equations in the frontend

[Lennart Ochel]

model test
  Real a(min=0), b(min=0), c(min=0);
initial equation 
  a+b+c=0;
  a+b+c=0;
  a+b+c=0;
equation 
  der(a) = 0;
  der(b) = 0;
  der(c) = 0;
end test;

I get this warning:

[:0:0-0:0] Warning: Assuming fixed start value for the following 2 variables:
         a:VARIABLE(min = 0.0 ) .test, .Real type: Real 
         b:VARIABLE(min = 0.0 ) .test, .Real type: Real

After instantiateModel the model looks like the following:

class test
  Real a(min = 0.0);
  Real b(min = 0.0);
  Real c(min = 0.0);
initial equation
  a + b + c = 0.0;
equation
  der(a) = 0.0;
  der(b) = 0.0;
  der(c) = 0.0;
  end test;

This shouldn't be the case, because I specified three initial equations and there is exactly one solution for the initialization problem.
Hence, I think we shouldn’t remove duplicated initial equations in the front end.

[Lennart Ochel]

Maybe we will get over-determined systems if we do no longer remove duplicated initial equations. But that should be handled in the back end. We have already a first approach to handle over-determined systems. If that approach is not able to handle such cases, it needs to get improved – of course. But it is hard to develop/test such approaches if the initial equations are already removed before the initialization process starts ;-).
If someone can show me where this is performed and how to deactivate this feature I can check if we get problems.

[Martin Sjölund]

I'm unsure what would remove equations... Maybe the handling of extends (because the same equation inherited multiple times is removed)?

[Adrian Pop]

This happens in Inst.mo:

        // Add equation and algorithm sections from base classes.
        eqs_1 = joinExtEquations(eqs, eqs2, callscope);
        initeqs_1 = joinExtEquations(initeqs, initeqs2, callscope);
        alg_1 = joinExtAlgorithms(alg, alg2, callscope);
        initalg_1 = joinExtAlgorithms(initalg, initalg2, callscope);

joinExtEquations uses:

List.unionOnTrue(inEq, inExtEq, SCode.equationEqual);

So that's why only one equation remains.

We could change joinExtEquations to add the extends equation
only if is not already there.

[Martin Sjölund]

But then what happens if you extend model test? You still need to inherit as many equations as there were in the base model.

[Adrian Pop]

That's a good question.
Maybe we should check how many of the same equation is in the
extends list and how many in the current list and warn if the
numbers are different.

model test
  Real a(min=0), b(min=0), c(min=0);
initial equation 
  a+b+c=0;
  a+b+c=0;
  a+b+c=0;
equation 
  der(a) = 0;
  der(b) = 0;
  der(c) = 0;
end test;

model test2
  extends test;
initial equation 
  a+b+c=0;
  a+b+c=0;
  a+b+c=0;
  a+b+c=0;
end test2;

How does test2 should look like after flattening?
I think this is a question for Modelica Association,
maybe we should add a ticket about this.
Maybe for initial equations we should not merge the
same equations?

[Martin Sjölund]

And ... what does test3 look like? 1 or 3 equations?

model test3
  extends test;
end test3;

[Per Östlund]

For what it's worth, removing syntactically equivalent equations from base classes is deprecated since at least 3.2rev2 (last section of 7.1 of spec). But as usual it's probably used everywhere anyway, so not removing equations is perhaps not an option.

[Per Östlund]

I tried replacing the List.unionOnTrue with a listAppend in Inst.joinExtEquations, and to my surprise none of the test cases failed (except for flattening/modelica/extends/IdenticalEquations.mo of course). So maybe we should stop removing duplicate equations by default, and maybe add a flag for turning removal on if anyone needs it anyway. Or does anyone have a good reason for keeping it?

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

[Henrik Tidefelt]

Yes, it would be good if equivalent equations were not removed by default. Removing equivalent equations messes up the equation counting when two equivalent equations are added accidentally. (Detecting equivalent equations is still very useful, and should always result in a warning or error during checking or translation, depending on whether the model is globally balanced or not.)

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

[Per Östlund]

The new frontend does not remove duplicate equations, since as mentioned it's been deprecated in Modelica since a long time ago. It also doesn't really seem to cause any issues, so we can probably consider this fixed.