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: | 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 , 8 years ago
Component: | *unknown* → Backend |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 7 years ago
comment:3 by , 7 years ago
Cc: | added |
---|
calculateStrongComponentJacobians takes some time... (Note: double values because it runs for initialization and simulation)
Using
--initOptModules-=calculateStrongComponentJacobians --postOptModules-=calculateStrongComponentJacobians
gives a compilation time of 64.60s (N=1800), 1801 non-linear systems, runtime of 56.2s. HavingcalculateStrongComponentJacobians
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.