Mechanics.MultiBody.Examples.Constraints.PrismaticJoint

[Martin Sjölund]

Modelica.Mechanics.MultiBody.Examples.Constraints.ConstrainPrismaticJoint.mos still fails. But only on 64-bit 12.04 Ubuntu with gcc 4.4.

On Mint 14 (Ubuntu 12.10) and when using clang, it works fine. This could mean something changed in the compilers, but I doubt it since it's only tiny vendor patches that differ between the two:
12.04: gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-1ubuntu2)
12.10: gcc version 4.4.7 (Ubuntu/Linaro 4.4.7-2ubuntu1)

I had a thought it could be compiler settings that changed (I didn't use -march=native on my laptop in order to please valgrind).

It could possibly be that the linear solver changed. But it didn't since it seems we use our own f2c-translated copy of LAPACK internally! (Willi, why do we use our own version of LAPACK in the simulation executables? omc.exe itself is linked with LAPACK anyway...)

For 12.04 (which does produce a correct executable), I get:

Error: When solving linear system ...
[
  0.0 , -0.9663834860128886 , 0.0 , 1.0 ;
  -0.5648625214636235 , 0.0 , -0.8191520442889918 , 0.09960050292505122 ;
  0.0 , -0.21486551488510405 , 1.0 , 0.0 ;
  1.0 , 0.14119408087712543 , 0.0 , 0.0
]
  *
[
  bodyOfConstraint.body.frame_a.r_0[3] ;
  freeMotionScalarInit.r_rel_a_1 ;
  bodyOfConstraint.body.frame_a.r_0[1] ;
  bodyOfConstraint.body.frame_a.r_0[2]
]
  =
[
  0.0 ;
  0.0 ;
  0.0 ;
  0.0
]

(I changed the rhs to all zeroes, which is what the backend used; but I don't get why (1) it fails - all zeroes has a trivial solution provided all x are set in the matrix. (2) why we enter all zeroes on the rhs instead of evaluating the rhs!)

So why did it succeed at evaluating the system on 12.04, but still fail later? Anyway, if dgesv failed for a constant zero rhs we should change linear system solver ;)

Or why did it not even try evaluating the system on 12.04? Note that the system-provided LAPACK is used for both of these versions. Jens, I think we should just rewrite analyzeConstantJacobian to be a little smarter.

I looked at the generated _info.xml and the equations generated are indeed different for the two compilers.

For test.openmodelica.org, 6 more linear system are generated than on my laptop (I guess 3+3 initialization).

If you got this far, you are braver than me. I didn't go up to check that the text is coherent.

[Martin Sjölund]

Looking through the equation-system that failed, it is a constant matrix with variables only on the rhs

matrix is:

0,X,0,X
X,0,X,X
0,X,X,0
X,X,0,0

solve for a1, r1, r2, r3

rhs is:

0.23702889650558212 * a2 + r[2] + -0.09960050292505122 * a3
-0.8191520442889918 * r[1] + 0.09960050292505122 * r[2] + -0.5648625214636235 * r[3]
-0.5318108111446446 * a2 + r[1] + 0.8191520442889918 * a3
0.8130157214783864 * a2 + r[3] + 0.5648625214636235 * a3

If the matrix itself is full of constants (like here), can't we solve it by using our own symbolic gaussian elimination? It's so simple even I think I know how to do it (although I don't have the time). And you would get a compile-time error if it failed...

[Willi Braun]

It's really strange, since it works on my Ubuntu 12.04 with:
gcc-4.4 (Ubuntu/Linaro 4.4.7-1ubuntu2) 4.4.7

It could possibly be that the linear solver changed. But it didn't since it seems we use our own
f2c-translated copy of LAPACK internally! (Willi, why do we use our own version of LAPACK in the
simulation executables? omc.exe itself is linked with LAPACK anyway...)

That's a good question, I will change that.

I'm not brave to you since I stopped the mindful reading, after the above sentence :P,
but I'm will came later to it again...

[Martin Sjölund]

If possible, it would be nice to have a second linear solver to try in the runtime. Maybe the system could have been solved. It would have been good to be able to see the actual evaluted matrices Ax=b that it failed on to see if there really was no solution...

[Willi Braun]

Beyond all question, an other linear solver and a faster one, would be nice.

But however as far as I see the solver is *not* the solution to this issue here, since the system is just not solvable it's singular, this means we solve different system in different set up, what is quite bad and the actually reason why the models behaviour different in different set up.

It's a can't reproduce the hudson gcc behaviour, so it's hard to debug that.
Martin, do you know any differences between, build.openmodelica.org and dev.openmodelica.org ?
So that it would be possible to me to reproduce that hudson gcc behaviour.

[Martin Sjölund]

There is no difference at all between build, test, testone and dev.openmodelica.org. Same OS everywhere.

[Martin Sjölund]

Postponed until 1.9.1

[Willi Braun]

Currently that model simulates, but with a different result(wrong?) as dymola.
It seems to be an initialization issue we get the same result,
if we initialize with the dymola file.

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