OMEdit should not hang for more than a few seconds

[casella]

A typical end-user experience when using OMEdit is that some action is initiated via the GUI, the pointer turns into an hourglass for a long (sometimes very long) time, without any possibility of interaction and without any feedback. This is quite annoying and gives a general impression of lousiness of the tool, as one has no idea if and when he/she will be back in control.

For operations involving the browsing of libraries and the graphical building of models by dragging and dropping, the problem is well-known, see #2960, and it should hopefully be solved by the new API based on the new front-end, which is expected to be one order of magnitude faster or more.

For operations like starting a simulation, however, the availability of the new front end will not be enough. There are reasonable and not particularly large end-user models that can take one or two minutes for flattening, back-end processing and code generation. During this time, the end-user should continuously get feedback about what is going on, as well as be allowed to do other things with OMEdit that do not involve the current simulation, e.g., browsing simulation results or other Modelica models. No more hourglass, please :)

In particular, the "Compilation" tab of the simulation output windows should report at least the main milestones of the code generation, such as those that you can get out of -d=exectstat, see also #3565 and the discussion therein.

It could also be nice if the bottom slice of the OMEdit window, which contains the Modelling, Plotting and Debugging tab selectors, also showed some indication of the CPU and disk activity of the OMEdit process and of its children, which can be very resource-intensive, as we all know. In this way, one gets a feeling that OMEdit is doing something and is not simply stuck. On Windows, I always run the Task Manager for this purpose, and htop on Linux, but that's not something that the newbie user would do, and it's not particularly user-friendly anyway.

Last, but not least, it should be possible to abort the compilation of a model anytime, also during the first phases such as flattening. If one accidentally starts a very lengthy compilation it makes no sense that he/she needs to wait forever for it to be finished, or, even worse, to kill the OMEdit process, restart it, and reload all the libraries and all the simulation results manually.

IMO, this feature is really needed to convey a professional feeling of the OMEdit GUI, so we should aim at getting it for 2.0.0.

[adeas31]

There are too many things compiled in this ticket. Lets dissect them,

• OMEdit being not responsive is mostly because of slow frontend. (A new promised frontend and API will surely improve this).
• Being able to use OMEdit during the flattening of the model also requires better API. Right now its just a function call with undefined return time. We could make it asynchronous call and then compiler should invoke some callback function when its done. Note that the compiler should be able to receive new calls during the flattening process otherwise making OMEdit is of no use. (Should be a new ticket with component Interactive Environment.)
• LOG_STATS can be used to report the main milestones of the code generation. (Should be a new ticket or use #3565.)
• OMEdit showing the disk activity and process status is a new enhancement and can be moved to a new enhancement ticket.
• Its already possible to abort the model compilation. I think you are referring to translation. But as I said earlier this requires a better API. There should be a possibility in API to cancel the running operation i.e, translation.

I personally think that we should have separate tickets for them and perhaps use this ticket as a summary ticket.

[casella]

Replying to adeas31:

There are too many things compiled in this ticket. Lets dissect them,
I personally think that we should have separate tickets for them and perhaps use this ticket as a summary ticket.

I agree. I'll try do do this ASAP. Some comments first.

• OMEdit being not responsive is mostly because of slow frontend. (A new promised frontend and API will surely improve this).

Regarding editing of models, I agree, the goal is to rely on a front-end which is fast enough to permit real-time or near-to-real-time GUI operation. When it comes to translating models to simulation code, the front-end is only one part of the story, and I expect the back-end and simcode part will be the next bottleneck once the NF is in place.

• Being able to use OMEdit during the flattening of the model also requires better API. Right now its just a function call with undefined return time. We could make it asynchronous call and then compiler should invoke some callback function when its done. Note that the compiler should be able to receive new calls during the flattening process otherwise making OMEdit is of no use. (Should be a new ticket with component Interactive Environment.)

This is of course one option, but allowing the compiler to process multiple calls in parallel seems to me like a major development, which we may not be able to afford for a long time, and maybe is not even that necessary. I think we need a viable, low-cost solution that can be implemented in 2.0.0.

I was thinking of something like OMEdit spawning a new thread that calls the function and waits for it to return, while still being able to perform tasks that do not involve talking to the compiler via the API, e.g., moving around windows, examining simulation results, etc.. This is only partially possible today, e.g. I can minimize the OMEdit window during translation, but I can't resize it, nor I can switch from the Modelling tab to the Plotting tab and look at plots, all operations that do not require talking to OMC but rely (or can rely) exclusively on internal OMEdit data structures.

This would require to have a semaphore somwhere that is set whenever the API is called and prevents the execution of all API-related callback functions, while allowing all the other ones to be called. Would that be possible?

• LOG_STATS can be used to report the main milestones of the code generation. (Should be a new ticket or use #3565.)

If you mean that we get LOG_STATS to output information during the process and not only at the end, that's one idea. What I'd like to see from a GUI perspective is a tab in the Simulation Output windew that shows that stuff is going on (which is way better than staring at a hourglass and wondering if the thing ended up in an infinite loop), without giving much detail, which is only relevant to developers. That's the end-user requirement. I think just reporting the end of frontend, backend, templates, simcode and C compilation is not fine-grained enough, because in some cases you could easily wait a minute or more between them. We need to report something on a more fine-grained scale, e.g. the end of each operation reported by -d=execstat, but without all the detail which is currently there, that is too technical.

• OMEdit showing the disk activity and process status is a new enhancement and can be moved to a new enhancement ticket.

Agreed. This should be integrated with the previous point, since it's part of showing that stuff's going on. I guess also memory allocation would be good to monitor, as it is quite easy to hit the RAM limit with not-so-small models.

• Its already possible to abort the model compilation. I think you are referring to translation.

Of course.

But as I said earlier this requires a better API. There should be a possibility in API to cancel the running operation i.e, translation.

Definitely, as the translation operation can take a long time, even with the new front-end and all the improvements we can think of. If you press the "Simulate" button by mistake (e.g., you realize you haven't changed all the parameters you wanted to change) you shouldn't be faced with the choice between waiting for an indefinite amount of time or killing the OMEdit process and restart from scratch, which takes some time anyway.

I'm not sure how this could be designed, but having at least the option of interrupting the process at the end of each function reported by -d=exectstat could be a good starting point. And of course when you press the abort button, rather than a hourglass you should get a message like "Waiting for phase XXX of the translation process to terminate", or something similar.