Over-determined system

[Nimalk]

When setting the initialization parameters for the Multibody components the system becomes over-determined. E.g. by setting the r_0 parameter for the bodyShape component.

When instantiating model:

"Check of test completed successfully.

Class test has 915 equation(s) and 921 variable(s).
618 of these are trivial equation(s).
"

and when simulating:

Symbolic	14:57:07		0:0-0:0	Too many equations, over-determined system. The model has 924 equation(s) and 921 variable(s).

A notable thing is that the numbers of equations, when instantiating and simulating, are not the same.

Furthermore, the number of variables and equations are not the same, when just using a bodyShape and a world component without connecting them together.

"Check of test1 completed successfully.


Class test1 has 912 equation(s) and 921 variable(s).
615 of these are trivial equation(s).
"

[Lennart Ochel]

Check model counts only the variables/equations of the simulation. Hence, this may differ for the initialization (your error message during compilation is probably related to the initialization). But, if the number of equations/variables do not even match for simulation, this needs to be fixed first.

[nimalk@…]

Replying to lochel:

Check model counts only the variables/equations of the simulation. Hence, this may differ for the initialization (your error message during compilation is probably related to the initialization). But, if the number of equations/variables do not even match for simulation, this needs to be fixed first.

Could you please tell me where to set the r_0 start value (I know, I can set it in text view, but I cannot find it in the Component Parameters dialog)? The only parameter I can see, for the body component, is r_0 and changing that gives me an over-determined system. Which gives sense, since it's not the start value, even its located in Initialization, which might be a little bit confusing, since the start values is not shown.

Regarding your answer to the number of equations and variables, I still do not understand, why I can simulate a system which is under-determined, according to your verification. I have tested my model in Dymola and Wolfram SystemModeler without any problems and I gets the same amount of equations as variables. I still think it is a bug in OpenModelica.

You can test the following simple model. If you verify the model, you will get 912 equations and 921 variables. In the given case we are talking about an under-determined system and for that reason, it should not be possible to simulate the model, but it is in OpenModelica.

model test
  Modelica.Mechanics.MultiBody.Parts.BodyShape bodyshape1 annotation(Placement(visible = true, transformation(origin = {47.7477,-39.3393}, extent = {{-10,-10},{10,10}}, rotation = 0)));
  inner Modelica.Mechanics.MultiBody.World world annotation(Placement(visible = true, transformation(origin = {7.50751,33.3333}, extent = {{-10,-10},{10,10}}, rotation = 0)));
  annotation(Icon(coordinateSystem(extent = {{-100,-100},{100,100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2,2})), Diagram(coordinateSystem(extent = {{-100,-100},{100,100}}, preserveAspectRatio = true, initialScale = 0.1, grid = {2,2})));
end test;

[Francesco Casella]

Note that we've had the same problem for some time in the standard MultiBody library, where there are a few examples with bodies unconnected to ground (e.g. Modelica.Mechanics.Multibody.Examples.Elementary.PointGravity). The models simulate correctly, and have been doing so for a long time, it's just the check phase that reports wrong numbers.

[Adrian Pop]

Yes, this is a case of wrong equation counting.
Probably some array/complex equations are not counted to the correct dimensions.
Running this script:

loadModel(Modelica); getErrorString();
loadFile("testcounting.mo"); getErrroString();
checkModel(testcounting); getErrorString();
buildModel(testcounting); getErrorString();

builds the model just fine:

adrpo@ida-liu050 ~/dev/OpenModelicaNoChanges/build/bin
$ ./omc testcounting.mos
true
""
true

"Check of testcounting completed successfully.


Class testcounting has 912 equation(s) and 921 variable(s).
615 of these are trivial equation(s).
"
""
{"c:/bin/cygwin/home/adrpo/dev/OpenModelicaNoChanges/build/bin/testcounting","testcounting_init.xml"}
"Warning: The initial conditions are not fully specified. Use +d=initialization for more information.
"

[nimalk@…]

Thank you for your urgent response. Since the model can be built and made to function in spite of the check model returning errors, I will now attempt to disable the check model in order to solve the problem at hand.

Meanwhile, could you please tell me where to set the r_0 start value (I know, I can set it in text view, but I cannot find it in the Component Parameters dialog)?

The only parameter I can see for the body component is r_0. Changing that gives me an over-determined system, which makes sense as it's not the start value, even though it is located in Initialization, which might be a little bit confusing, since the start values are not shown.

[Francesco Casella]

Replying to nimalk@…:

Meanwhile, could you please tell me where to set the r_0 start value (I know, I can set it in text view, but I cannot find it in the Component Parameters dialog)?

The only parameter I can see for the body component is r_0. Changing that gives me an over-determined system, which makes sense as it's not the start value, even though it is located in Initialization, which might be a little bit confusing, since the start values are not shown.

r_0 is not a parameter, it is a variable. The fact that it is shown in the Parameters window, Initialization tab, is a bug in OMEdit, because if you write, say, {1, 0, 0} there, you get a modifier

r_0 = {1, 0, 0}

while you'd need

r_0(start = {1, 0, 0})

and possibly

r_0(start = {1, 0, 0}, fixed = true)

This is related to #2390, which hasn't been addressed yet. I would encourage Adeel to fix that with high priority.

[nimalk@…]

Thank you for your interesting information, which I am contemplating.

Of course is r_0 not a parameter, but a variable.

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