Opened 9 years ago
Last modified 3 years ago
#3565 new defect
OMC does not tell the user what it is doing
| Reported by: | Francesco Casella | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | |
| Component: | *unknown* | Version: | |
| Keywords: | Cc: | andrea.bartolini@… |
Description (last modified by )
When compiling models of significant size (not necessarily very large), omc can take a few minutes (or possibly hours) to complete the process. It is often the case that nothing is printed to the console or log file for a long time, so one doesn't have a clue about what is happening, and can only stare at a blank window, wait indefinitely and hope for the best. This can be really frustrating from an end-user perspective.
Proposal:
- add a debug flag (e.g.
+d=logCompilationPhasesthat prints a message on stdout every time a major phase in the compilation process is started (e.g. front-end, back-end, simcode, templates, C compilation), and that records the time spent for each phase once completed - add a debug flag (e.g.
+d=logCompilationPhasesDetailedthat prints a message on stdout every time a specific activity is started (e.g. for the back-end it could be every single optimization module, for the front-end and code generation I don't know) and record the time spent for each phase once completed - flush the stream after each message is written, so that it can actually be captured by the console or by OMEdit, displayed in a timely manner, and not get lost if the process needs to be killed because of timeout or too much memory allocation
All these messages could have some common header, so that OMEdit can filter them out and display them nicely in some window showing the progress in the compilation phase.
Change History (14)
comment:1 by , 9 years ago
| Description: | modified (diff) |
|---|
follow-up: 3 comment:2 by , 9 years ago
comment:3 by , 9 years ago
Replying to sjoelund.se:
Or perhaps translateModel(..., logCompilationPhases="path/to/something.json")? If it is only for OMEdit, we could do something similar as we do for the plot command, where OMEdit provides a call-back function plus data for a unique ID that directly updates the GUI window.
These could both be combined (and have a compiler flag as well to log this when run from the command-line).
That would be nice!
comment:4 by , 9 years ago
In the meantime, Martin suggested us the following combination of flags: -d=gcProfiling,exectstat and --showErrorMessages, which indeed gave us a lot of useful information for debugging.
Also, we found out that running omc test.mos > log.txt under Linux doesn't work well, because the OS is somehow lazy at copying the output from stdout to the log file. omc test.mos |& tee log works much better from this point of view.
comment:8 by , 8 years ago
| Milestone: | 1.11.0 → 1.12.0 |
|---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:9 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.
comment:11 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:13 by , 4 years ago
| Milestone: | 1.17.0 → 1.18.0 |
|---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
Or perhaps translateModel(..., logCompilationPhases="path/to/something.json")? If it is only for OMEdit, we could do something similar as we do for the plot command, where OMEdit provides a call-back function plus data for a unique ID that directly updates the GUI window.
These could both be combined (and have a compiler flag as well to log this when run from the command-line).