Opened 8 years ago

Last modified 7 years ago

#4420 assigned defect

OpenModelica hangs for minutes on examples that are otherwise solvable in milliseconds

Reported by: Ali Baharev <ali.baharev@…> Owned by: Patrick Täuber
Priority: high Milestone: Future
Component: Backend Version: v1.11.0
Keywords: Cc: Willi Braun

Description

Example 3:

https://github.com/baharev/failure-modes-of-tearing/blob/master/tearing_enabled/example_3.mo

of

https://github.com/baharev/failure-modes-of-tearing/blob/master/failure_modes_of_tearing.pdf

was designed to test the effects of fill-in. The parameter N of the model can be changed. The latest release of Dymola hangs for more than 6 minutes (with N=500) when tearing is enabled, but the situation is slightly better if I disable tearing.

OpenModelica on the other hand hangs for reasons that seem to have nothing to do with tearing. I suspect that OpenModelica falls into a so-called O(n2) trap, but I failed to track down the exact causes.

If you fix this issue, make sure you understand Section 3.3 of the paper too, and test what happens in OpenModelica.

In my opinion, applying tearing by default, and without any caution, is the wrong default.

A better default would be to check whether tearing eliminated "sufficiently many" variables (say, at least 2/3 of all variables AND at least 10 variables, so I propose checking it in both absolute and relative terms). If tearing did not eliminate "sufficiently many" variables, disable tearing, and use sparse linear algebra instead, especially if the original problem is sparse.

Here, the "sufficiently many" is somewhat arbitrary, and one would have to test it on a reasonable benchmark suite; the above 2/3 and 10 were arbitrary.

In any case, eliminating just a single variable, and turning an otherwise sparse problem into a completely full problem is not acceptable (and that is precisely what Dymola does).

I am available for discussion in person at the 12th International Modelica Conference 2017; I will stay at the Clarion Congress Hotel.

Change History (3)

comment:1 by Lennart Ochel, 8 years ago

Component: *unknown*Backend
Owner: changed from somebody to Patrick Täuber
Status: newassigned

comment:2 by Martin Sjölund, 7 years ago

calculateStrongComponentJacobians takes some time... (Note: double values because it runs for initialization and simulation)

NtimeJacobiansTearingSorting/Matching
300 2.32 0.14 0.15 0.49
600 9.06 1.14 0.57 2.00
900 22.61 4.33 1.41 5.73
1800 91.69 28.71 5.03 18.25

Using --initOptModules-=calculateStrongComponentJacobians --postOptModules-=calculateStrongComponentJacobians gives a compilation time of 64.60s (N=1800), 1801 non-linear systems, runtime of 56.2s. Having calculateStrongComponentJacobians enabled does not result in a faster simulation.

Using --initOptModules-=calculateStrongComponentJacobians,tearingSystem --postOptModules-=calculateStrongComponentJacobians,tearingSystem gives a compilation time of 47.09s (N=1800), same number of non-linear systems, but runtime increases to 1m40s since it seems to not perform the calculations during initialization only.

comment:3 by Martin Sjölund, 7 years ago

Cc: Willi Braun added
Note: See TracTickets for help on using tickets.