Very ill-conditioned initialization in ComparisonPullInStroke

[henrikt-ma]

I'm a bit concerned regarding the initialization of Modelica.Magnetic.FluxTubes.Examples.SolenoidActuator.ComparisonPullInStroke. When translated with System Modeler, I get a linear equation system with a condition estimate in the order of 10^15. The equation system in question is the one with variables der(simpleSolenoid.g_mAirWork.Phi), der(simpleSolenoid.g_mAirWork.V_m) and der(simpleSolenoid.g_mLeakWork.Phi). The exact list of variables may vary from tool to tool, but I expect this information to be sufficient to allow others to identify which equation system I'm talking about.

Can it be considered normal or a defect of the MSL to have such poorly conditioned equation systems?

In case it is considered normal, it would be interesting to hear if the developer of this model has any thoughts about how to handle such equation systems while at the same time being able to avoid arbitrary results for systems even closer to "true" singularity. (I have some ad-hoc plans in mind, but their lack of elegance makes me reluctant to share them.)

[henrikt-ma]

OK, a rather elegant solution at the price of some simulation performance would of course be to precondition the linear systems with scaling matrices. For the system at hand, I think that one would need both row and column scaling to "correctly" determine – with some margin of error – that this is a full-rank system. With less requirements on margin of error, either row or column scaling would be sufficient.

Is the modeler in this case correctly assuming that preconditioning will be used to mitigate numeric problems with badly conditioned equation systems?

(I'm also noting that column scaling based on nominal can't solve this problem efficiently as we have no good way of attaching nominal values to derivatives.)

[HansOlsson]

I have not yet been able to confirm that this is an actual problem.

[henrikt-ma]

I have not yet been able to confirm that this is an actual problem.

It has been flying under our radar until now, so in that regard I am not completely surprised if it still goes undetected also with other tools.

[HansOlsson]

To clarify: Dymola does not generate any linear systems of equations for that model so clearly no ill-conditioned ones. Only linear scalar equations and non-linear system of equations that don't seem to be problematic. So that makes it more important to get a full description of the potential problem.

[henrikt-ma]

That might be related to how this used to be flying under the radar of System Modeler: the 3 by 3 linear system gets torn to a scalar division, making potentially hazardous numeric conditioning easy to miss.

[AHaumer]

Unfortunately I'm not really familiar with this (tricky) example, but you should contact the authors @ThomasBoedrich and Johannes Ziske (TU Dresden).

[henrikt-ma]

Another example on the same theme is ModelicaTest.Magnetic.QuasiStatic.FluxTubes.NoPhysicalTestLeakage. I can only speak for System Modeler here, but there the initialization of Phi1.im is a linear system of size 5 which is reduced to a scalar division by tearing. The condition number of the untorn 5 by 5 system is in the order of 10^8, and it turns out that standard LAPACK equilibration doesn't really improve the condition number in this case.

Better preconditioning by row and column scaling exists, but I'm questioning that tools should be expected to find more sophisticated scalings than the simple equilibration.

Would the modeler expect some sort of warning for a system like this, or is a condition number of 10^8 considered good enough to silently treat the equation system as being well-determined?