Opened 8 years ago
Last modified 3 years ago
#4006 assigned defect
SimCode scales as O(N^2) in models with many when clauses and events
Reported by: | Francesco Casella | Owned by: | Willi Braun |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Backend | Version: | |
Keywords: | Cc: | Willi Braun |
Description
Consider these two models from the ScalableTestSuite
model ManyEvents "Model with many events in when clauses" parameter Integer N; Real x[N](each start = 0, each fixed = true); Boolean e[N](each start = false, each fixed = true); equation for i in 1:N loop der(x[i]) = 1/i; when x[i] > 1 then e[i] = true; end when; end for; end ManyEvents; model ManyEventsManyConditions "Model with many events in when clauses and a when clause with many triggering conditions" parameter Integer N; Real x[N](each start = 0, each fixed = true); Boolean e[N](each start = false, each fixed = true); Integer v(start = 0, fixed = true); equation for i in 1:N loop der(x[i]) = 1/i; when x[i] > 1 then e[i] = true; end when; end for; when e then v = pre(v) + 1; end when; end ManyEventsManyConditions;
It is apparent that the second one has one additional scalar equation, whose when clause is triggered by a vector e
with N
components.
This is the performance of SimCode: create system equations on my pc for the first model
N | Time [s] |
---|---|
1000 | 4.3 |
2000 | 18.0 |
4000 | 87.6 |
which scales as O(N2.5). For the second model, instead, I get:
N | Time [s] |
---|---|
1000 | 0.02 |
2000 | 0.05 |
4000 | 0.14 |
which seems quite weird, as a model with one additional equation takes two order of magnitudes less time.
This actually happens at the expense of the time spent by encapsulateWhenConditions
, see #4005.
Is there a way to avoid the blow up with N of the combined SimCode and encapsulateWhenConditions execution time?
Change History (17)
follow-ups: 3 6 comment:1 by , 8 years ago
comment:2 by , 7 years ago
Milestone: | Future → 1.12.0 |
---|---|
Summary: | Weird performance of SimCode in models with many when clauses and events → SimCode scales as O(N^2) in models with many when clauses and events |
comment:3 by , 7 years ago
Status update: regarding ManyEvents
, the situation with SimCode
execution times is unchanged.
Any chance to fix this?
comment:4 by , 7 years ago
Component: | *unknown* → Run-time |
---|
comment:5 by , 7 years ago
Milestone: | 1.12.0 → 1.13.0 |
---|
Milestone moved to 1.13.0 due to 1.12.0 already being released.
follow-up: 8 comment:6 by , 7 years ago
For ManyEvents
, SimCode
now seems to be linear:
N | Time [s] |
---|---|
4000 | 0.9565 |
8000 | 2 |
Shall we close this ticket?
comment:7 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Indeed. I'm not sure when this was actually fixed, I missed the change as I was recently focusing more on the new front end performance.
Thanks for pointing this out!
comment:8 by , 7 years ago
Replying to hkiel:
For
ManyEvents
,SimCode
now seems to be linear:
N Time [s] 4000 0.9565 8000 2 Shall we close this ticket?
Which run did you observed?
Since in the last ODE ScalableTestsuite it seems to be still an issue:
N | Time [s] |
---|---|
2000 | 5.39 |
4000 | 27.95 |
8000 | 123.08 |
comment:9 by , 7 years ago
@wbraun I'm referring to https://test.openmodelica.org/libraries/ScalableTestSuite_Experimental/BuildModelRecursive.html 2018-03-20 with --daeMode=new
comment:10 by , 7 years ago
Cc: | added |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
This issue is not fixed. It is only hidden in daeMode.
comment:11 by , 7 years ago
Component: | Run-time → Backend |
---|---|
Owner: | changed from | to
Status: | reopened → assigned |
Ah, so it's fixed in the DAEmode, but not in ODE.
I think the issue is actually that we generate in SimCode phase all equation at least two times, see the function
createEquationsForSystems.
comment:12 by , 7 years ago
Priority: | high → normal |
---|
Of course it would be good that this issue is fixed for ODE mode also.
On the other hand, I guess that when the size of the problem is large enough for this issue to be relevant, DAE mode may be necessary anyway, and that works fine, so I would consider this "almost" fixed.
It is instead absolutely essential to fix #3905, otherwise large systems with events are not really feasible in OMC.
comment:14 by , 5 years ago
Milestone: | 1.14.0 → 1.16.0 |
---|
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
comment:16 by , 4 years ago
Milestone: | 1.17.0 → 1.18.0 |
---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
Status update:
ManyEventsManyConditions
is now fine. After fixing #4005, neither theencapsulateWhenConditions
function norSimCode
do blow up.Regarding
ManyEvents
,SimCode
now takes O(N2) time on libraries.openmodelica.org:Still something badly wrong in there, probably a list not handled correctly.