OMEdit should not switch to plotting perspective when simulation fails

[massimo ceraolo]

OMEdit switches to plotting perspective even when a simulation fails. This is not good, since gives the user a false feeling that the simulation succeeded.

I propose not to automatically switch perspective (thus to remain into the modelling perspective from where the simulate command was issued) if the simulation does not start.
Just to help reproduce the behaviour, In enclose TableTest.mo. If the right file is not in the OM work directory or if the right array is not read from the file, the simulation does not start, but OMEdit perspective is changed.

[Francesco Casella]

I completely agree. In fact, if the simulation does not start one needs to fix the source code of the model, so switching to the plotting tab is not a good idea also from this point of view.

[Adeel Asghar]

I also agree with this but as far as I remember this is done intentionally because in some cases the simulation fails half way and you have a result file that you can plot. I think there was a ticket about it.

From the code point of view its very easy for me to not switch to plotting perspective when a simulation fails. I believe its more about the user experience.

[massimo ceraolo]

Replying to adeas31:

I also agree with this but as far as I remember this is done intentionally because in some cases the simulation fails half way and you have a result file that you can plot. I think there was a ticket about it.

Maybe we can avoid switching when simulation does not start at all?
For instance when the error simulation terminated by an assertion at initialization is generated?

This is what occurs with the enclosed example. In this case there is nothing to plot. Currently OMEdit switches in the plot perspective, shows all the variables, and the user is implicitly prompted to have a look... Only to realise that everything is empty. Consequently he checks simulation output dialog box and sees the reason for that. This is not optimal, for me.

In case it is possible to avoid switching perspective only in case of "simulations terminated by an assertion at initialization", the user, if he wants, could still switch plot mode to have at look at the variable list, but only for debug.

[Adeel Asghar]

This is possible however is ugly since the GUI relies on string comparison. The message "simulations terminated by an assertion at initialization" comes from the simulation runtime and these kind of messages keeps on changing. I prefer a solution that we decide on whether to switch or not when simulation fails.

One solution is to use ​readSimulationResultSize API and if the result size is zero then don't switch.

[Francesco Casella]

As already discussed in #4486, from an end-user perspective, there is a fundamental difference between these three cases

• intialization fails
• initialization succeeds but simulation fails
• simulation succeeds

In the last two cases one can get a lot of valuable information by plotting whatever results were found (assuming they actually get saved to disk and are not stuck in some buffer limbo when a segfault happens), so obviously the plotting view should be activated. In the first case, alas, there is no such information, so the main source of info so far is the declarative debugger and the log messages (if they are activated), so activating the plotting view is just confusing.

I tried the solution proposed in comment:4 with this simple test script

loadString("
model Test
  Real x, y, z;
equation
  der(x) = y;
  y = 3*x;
  z = 1/x;
initial equation
  z = 0;
end Test;
");getErrorString();
simulate(Test);getErrorString();
readSimulationResultSize("Test_res.mat");getErrorString();

which obviously fails at initialization. Indeed, even though a mat-file is generated, the API function returns 0. So, this seems to me a good solution.

[Adeel Asghar]

I have implemented the solution I proposed in comment:4.
See da1155a/OMEdit.

[massimo ceraolo]

Thanks a lot! I will check tomorrow.

[massimo ceraolo]

Just checked on Linux. It works nicely.
Thank you again.