IDA solver in DAE mode is inefficient with badly scaled systems

[Francesco Casella]

Modelica models are often badly scaled because of the recommended use of variables in SI units, which often causes variables in the same model to differ by many orders of magnitude, up to 15 or more.

The Modelica language allows to define nominal values for the scaling of variables, that can be used to set up properly scaled numerical problems in the runtime code. However, this mechanism seem not to work properly when using the IDA solver in DAE mode.

The attached test case shows clearly the problem. The model is taken from #4395, with the end displacement d_tot no longer being a constant, but rather the solution of the trivial differential equation der(d_tot)=1.

Test1 is natively scaled in a benign way, with all variables of the order of unity or, in the worst case, of 1e-3.

Test2 is the same model as Test1 with much higher stiffness constants, so that some of the unknowns during integration (the vector F[N]) now have order of magnitude 1e8. Note that, apart from the scaling factor, the solution has exactly the same shape.

Test3 is the same model as Test2, with the proper nominal attribute set on the vector F[N]. In principle, if the model gets properly scaled according to this information, Test3 should numerically become exactly the same as Test1, and thus take more or less the same time to be solved. Note that is is only true if both the variables and the residuals are properly scaled.

The following table summarizes the results obtained on my PC with running omc v1.12.0-dev-354-gadf56d3 on Windows

Test	Steps	functionODE calls	Jacobian evaluations	Simulation time
Test1	18	33	16	8.17
Test2	16	26	14	97.30
Test3	16	26	14	100.85

Analyzing the results, one can take the following conclusions

• the number of steps is only decided by the trivial differential equation, and is thus roughly constant
• the time spent solving each step grows 10-fold for the badly scaled problem, though this only basically reflects a change in the units of variable F[N], not a change in the nature of the problem
• setting the nominal attribute on the badly scaled variables does not improve the situation - in fact, it makes it slightly worse

One can expect that similar problems will arise when using IDA in DAE mode to solve real-life problems; as soon as the units of the variables are such that their order of magnitude (and the order of magnitude of equation residuals) is much different, there will be a performance penalty of one order of magnitude (or possibly more, for larger models) in terms of simulation time.

I would suggest to investigate why this happens and to introduce the appropriate corrective measures, so that the simulation time of models Test1 and Test3 becomes comparable.

[Francesco Casella]

The current implementation of IDA/Kinsol alread takes into account the nominal values of unknowns for their scaling. Apparently, this is not enough, and it is necessary to also use information about the scaling of the residuals. This can be estimated for each residual by taking the scalar product of the corresponding row of the Jacobian with the nominal value vector.

[Willi Braun]

The issue here apprised by wrongly evaluated nonlinear systems in the algebraic part, so the performance issue is probably connected to #4395. However the wrongly evaluation is fixed in a4b8280/OMCompiler.

[Francesco Casella]

I re-ran the tests, and the results are indeed impressive, compared to the previous ones. It seems that the fixed bug was really a nasty one. Good that you found it :)

Test	Steps	functionODE calls	Jacobian evaluations	Simulation time (total)	Simulation time (net)
Test1	18	33	16	1.61	0.18
Test2	18	38	16	1.34	0.25
Test3	18	33	16	1.44	0.32

In this case explicit scaling via the nominal attribute is less critical, because I guess the IDA implementation is considering as a scaling factor for each variable max(abs(v), v.nominal) or max(abs(v.start), v.nominal) or something like that, so even in the absence of explicit nominal values the scaling is fine and the performance is ok. @wibraun, please confirm - if you could point out the code chunk in the source where the IDA scaling is set, for reference, that would be ideal.

In fact, the number of steps and jacobian evaluations for the nicely scaled system and for the badly scaled with nominal attributes is exactly the same, which is the expected behaviour, while the badly scaled system without scaling calls functionODE a few more times, which is also expected. Why it takes less time is a mystery to me, but the difference is not dramatic, and sometimes running times are a bit erratic due to cache misses and similar issues.

Note that, contrary to the case of the stand-alone KINSOL solver (see #4395), IDA does not require to provide residual scaling, but only variable scaling, as it probably computes residual scaling internally to provide them to KINSOL.

[Francesco Casella]

Self-contained test script

[Francesco Casella]

Based on the further analysis carried out in #4395, I have updated the test model in order to avoid symmetries that could artificially favour the solver. I also increased the coupling between the algebraic part and the differential part of the model, so that the differential equation to be solved is not trivial.

Note that the initialization is instead trivial, as the initial value for all the iteration variables is zero, because this test is only meant to stress the simulation part, not the initialization part.

These are the results, see the attached test-ida3.mos, where Test1 is the well-scaled model, Test2 the badly scaled one and Test3 the badly scaled one with nominal attributes.

Test	Steps	functionODE calls	Jacobian evaluations	Simulation time (total)	Simulation time (net)
Test1	122	369	46	1.51	0.24
Test2	122	400	50	1.89	0.45
Test3	122	369	46	1.87	0.44

It is apparent how the introduction of nominal attributes brings the number of steps, function calls and Jacobian evaluations back to exactly the same values obtained with the well-scaled system. This is the expected behaviour, namely, introducing nominal attributes restores the same performance obtained with the well scaled example.

However, the simulation time is not restored at all, and remains the same as with the badly scaled system. The perfomance penalty in this case is almost a factor 2 which, which, while not dramatic, is still quite significant. I would try to investigate why this is the case and see if we can get the simulation time of Test3 to be the same as with Test1.

Last, but not least, there is a huge gap between the time reported for simulation by the STATISTICS timer and the overall simulation time reported later as timeSimulation. I am not sure what this is due to (writing results to file, maybe?), and possibly if there is something wrong with the detailed simulation timers. Please investigate and make sure those figures are eventually consistent.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed