Opened 6 years ago
Last modified 3 years ago
#5382 assigned defect
Simcode scales badly for models with large-sized arrays and events
| Reported by: | Owned by: | Karim Adbdelhak | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Backend | Version: | v1.14.0-dev-nightly |
| Keywords: | Cc: | Francesco Casella, Andrea Bartolini |
Description
The attached model leaks around 10GB of RAM when run in OMEdit.
The RAM does not decrease even when the model is unloaded.
A second run leaks an additional 2GB.
Note: a machine with at least 32GB is required to simulate the model. It is possible to reduce the value of nx in the model to make it occupy less RAM but the leak is evident for large nx.
Attachments (1)
Change History (10)
by , 6 years ago
| Attachment: | Thermal1Dalgorithmic.mo added |
|---|
comment:1 by , 6 years ago
comment:2 by , 6 years ago
| Cc: | added |
|---|
comment:3 by , 5 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
My interpretation of Martin's comment is that it won't fix so I am closing this ticket. Feel free to reopen it.
comment:4 by , 5 years ago
| Resolution: | wontfix |
|---|---|
| Status: | closed → reopened |
| Summary: | Memory leak → Simcode scales badly for models with large-sized arrays and events |
I agree with Martin's judgement that there is no memory leak here. The problem is actually a different one. If you run the model with -d=execstat with different sizes of N, you get this kind of results for the Performance of simCode: created simulation system equations step
| N | Time/s |
| 1000 | 1.1 |
| 2000 | 4.2 |
| 4000 | 28.1 |
There is clearly a scaling problem here, which is probably among the ones listed in #4146. I guess this is also what causes the inordinate escalation of the allocated memory when N = 10000
The solution, as we all now understand, is to have fully vectorized backend and code generation. We can keep this ticket open as it contains a nice test case.
comment:5 by , 5 years ago
| Component: | OMEdit → Backend |
|---|---|
| Owner: | changed from to |
| Status: | reopened → assigned |
comment:6 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:8 by , 4 years ago
| Milestone: | 1.17.0 → 1.18.0 |
|---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
There is no memory leak that I can see by checking with
OpenModelica.Scripting.GC_get_prof_stats(). It's just that Linux has a limit to the number of times you can free memory using the calls used by libgc, so we have disabled giving back memory to the OS. The memory will be reused by OMEdit on the next run.