Nonlinear solver prints random strings instead of system names

[Martin Sjölund]

Nonlinear solver prints random strings instead of system names, for example the following:

[martin@mega msl32]$ for f in `seq 1 100`; do ./Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMEE_LoadDump |& grep -o "Error.*time" | uniq; done
Error solving nonlinear system r at time
Error solving nonlinear system  at time
Error solving nonlinear system  at time
Error solving nonlinear system false at time
Error solving nonlinear system 1553 at time
Error solving nonlinear system r at time
Error solving nonlinear system parameter at time
Error solving nonlinear system r at time
Error solving nonlinear system voltageController.addSat.k2 at time
Error solving nonlinear system  at time
Error solving nonlinear system true at time
Error solving nonlinear system false at time
Error solving nonlinear system  at time
Error solving nonlinear system 0K at time
Error solving nonlinear system `R at time
Error solving nonlinear system false at time
Error solving nonlinear system true at time
Error solving nonlinear system Real at time
Error solving nonlinear system voltageController.limiter.uMax at time
Error solving nonlinear system  at time
Error solving nonlinear system  at time
Error solving nonlinear system  at time
Error solving nonlinear system 1.0 at time
Error solving nonlinear system (null) at time
Error solving nonlinear system Џ/ at time
Error solving nonlinear system  at time
Error solving nonlinear system 1551 at time
Error solving nonlinear system x[1,1] at time
...

Running the executable through gdb always gives the same string (Error solving nonlinear system �K�). So something is fishy.

[Martin Sjölund]

Valgrind says (after disabling some SSE instructions valgrind does not handle)...

==560== Invalid read of size 4
==560==    at 0x49FFDF: solveHybrd (nonlinearSolverHybrd.c:421)
==560==    by 0x49F144: solve_nonlinear_system (nonlinearSystem.c:165)
==560==  Address 0xac6b464 is 12 bytes after a block of size 40 alloc'd
==560==    at 0x4C2B3F8: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==560==    by 0x41BAFE: setupDataStruc2 (in /mnt/mech/trunk/testsuite/simulation/libraries/msl32/Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMEE_LoadDump)
==560== Invalid read of size 4
==560==    at 0x49FFDF: solveHybrd (nonlinearSolverHybrd.c:421)

[Martin Sjölund]

Ok, this comes from not all equationInfo_reverse_prof_index being populated. I'll fix it.

[Martin Sjölund]

Ok, I fixed so reverse_prof_index is correct... But it seems const struct EQUATION_INFO equationInfo[811] = { does not list the equations in the order of their index, so the wrong one is chosen anyway :(

[Martin Sjölund]

Ok, running testsuite now. Hopefully my changes didn't break anything. If it didn't, we'll have this fixed (with some extra assertions added to the code that will make sure nonlinear systems will lookup the correct system).

[Martin Sjölund]

Wheee... r14995 fixed a ton of remaining small bugs. We no longer have equations with the same index or indices that are skipped. They are also all sorted and in order. I'm happy. Especially since if someone adds new stuff in the backend, it should be detected and the simulation executable abort :)

[Jens Frenkel]

I guess using List.sort to sort the equations is not the best solution because it has mostly a bad complexity. There must be a solution without sorting the equations. Normaly the equations should be generted in correct order. Maybe we do not take care on some placees which index the container equation (linear, nonlinear, mixed system) get.

[Martin Sjölund]

Virtually none of the equations are in order. Sort is cheap anyway (n*log n integer comparisons; 10000 equations are roughly 40000 comparisons; 200k eq = 1m compare). Feel free to rewrite it though. Should take no more than a day.