Opened 5 years ago

Last modified 3 years ago

#5974 reopened defect

OMEdit allows a second simulation to run before first one has quit which causes mysterious crashes

Reported by: julian@… Owned by: Adeel Asghar
Priority: blocker Milestone: 1.19.0
Component: OMEdit Version: v.1.15.0-dev
Keywords: Cc:

Description

If you click on the Simulate button while a simulation is already running (or being compiled) the second process clashes with the first one and either causes errors due to corrupted files, or a core dump if you are more unlucky.

It's likely that experienced users are avoiding this so they don't encounter it, but it's a problem in the following scenario.

You start up an example and decide that the default "Stop Time" of one second is too short, so you open the "Simulation Setup" dialog, change it to 10 seconds and click "Okay". Now you go back and click on the "Simulate with Animation", wait for a few seconds and it mysteriously crashes. Then you try again, wait for a few seconds, and it works.

The problem is caused by the "Simulation Setup" dialog unhelpfully kicking off a "Simulate" process when you clicked "Okay", which you didn't know about and you don't even want, because you're going to have to simulate it all over again to see it with animation.

At least make the simulate buttons inactive when there is already a simulation running so people don't get these crashes.

Change History (18)

comment:1 by Francesco Casella, 5 years ago

Milestone: Future2.0.0
Priority: highblocker
Resolution: fixed
Status: newclosed

Doing this properly is not completely trivial. If we disable the simulate button, the simulation executable crashes badly and does not report a correct signal, OMEdit will end up in a hung state.

I think this should definitely be fixed for 2.0.0, not sure we can do it for 1.16.0.

@adeas31, any comment about this?

in reply to:  1 ; comment:2 by anonymous, 5 years ago

As an engineer trying Modelica for the first time (and the friend of the OP who brought this to his attention) my tuppence is:

-It would make sense to make the default UI follow the typical workflow, either left to right or top to bottom. My expected workflow for a simulation would normally be: Set up model -> Check model -> Set up simulation parameters -> Run Simulation -> View results
In most respects the default toolbar along the top follows this, you have the viewing and shapes toolbars that are used in creating the model, then the Check toolbar, but then when you come to the simulation toolbar, the simulate buttons are before the settings button, which to me seems the wrong way round. I think the Setup button should be first.

-Having it default to run the simulation when you click on "OK" in the setup box is confusing. I'd expect to enter the simualation settings and then run the simulation I want (I'm a simple engineer so I choose the simulate with animation option!) I didn't notice the checkbox for simulate in the setup dialog (simple engineers don't always read as much they should!) so I was clicking OK on the setup dialog, then clicking Simulate with Animation (almost) immediately. This resulted in seemingly random crashes and much swearing!

Greying out the simulate buttons when one is running would be good, or some other way to indicate in the main window that a simulation is running. If you've already run a simulation and have hidden the pop up window behind the main one then it doesn't pop back in front so you have no way of knowing one is going on. Also, it might be neat to have three buttons instead of two on the setup window. So instead of "OK" (which is a bit ambiguous) and "Cancel" then how about "Simulate" (maybe add some checkboxes for with debugger, with animation etc), "Save Settings" (again some checkboxes for the options) and "Cancel.

in reply to:  2 ; comment:3 by Francesco Casella, 5 years ago

Replying to anonymous:

-It would make sense to make the default UI follow the typical workflow, either left to right or top to bottom. My expected workflow for a simulation would normally be: Set up model -> Check model -> Set up simulation parameters -> Run Simulation -> View results
In most respects the default toolbar along the top follows this, you have the viewing and shapes toolbars that are used in creating the model, then the Check toolbar, but then when you come to the simulation toolbar, the simulate buttons are before the settings button, which to me seems the wrong way round. I think the Setup button should be first.

I guess the underlying idea is that existing model with saved simulation options can be simulated right away without setup, which is a kind of optional feature. Also Dymola (our main competitor) has the setup button to the right of the simulate button, maybe that also nudged us towards this setup. But you may have a point here.

-Having it default to run the simulation when you click on "OK" in the setup box is confusing.

I definitely agree with that. I've been using OMEdit for some time now, but I'm always a bit taken aback when the simulation processs starts right away as I end the setup.

@adeas31, I would change the default setting to not simulate right away.

I'd expect to enter the simualation settings and then run the simulation I want (I'm a simple engineer so I choose the simulate with animation option!) I didn't notice the checkbox for simulate in the setup dialog (simple engineers don't always read as much they should!) so I was clicking OK on the setup dialog, then clicking Simulate with Animation (almost) immediately. This resulted in seemingly random crashes and much swearing!

You definitely have a point here as well. As I wrote in comment:1,I'm still a bit worried about the possibility of OMEdit ending in a locked state if something goes wrong with the initialization. But I guess we could at least grey out those buttons during the translation and C code compilation phase. That is unlikely not to return properly, and if it does, then OMEdit crashes anyway, while a low-level failure of the simulation executable doesn't cause OMEdit to crash.

@adeas31, do you think this is doable?

Greying out the simulate buttons when one is running would be good, or some other way to indicate in the main window that a simulation is running. If you've already run a simulation and have hidden the pop up window behind the main one then it doesn't pop back in front so you have no way of knowing one is going on.

We should definitely bring it back to front every time we simulate, @adeas31 what do you think?

Also, it might be neat to have three buttons instead of two on the setup window. So instead of "OK" (which is a bit ambiguous) and "Cancel" then how about "Simulate" (maybe add some checkboxes for with debugger, with animation etc), "Save Settings" (again some checkboxes for the options) and "Cancel.

I'm not sure, the possible number of combinations is quite large, and I don't like much the idea of duplication of commands in different places. Maybe the current setup is good enough without the default Simulate selection?

comment:4 by timswait@…, 5 years ago

Thank you for taking the time to respond, I'm slowly getting to grips with Modelica and think it will prove useful for me when I do work out how to use it properly!

comment:5 by timswait@…, 5 years ago

Also the simulation setup options don't seem to stick if you change them after you've run a simulation. If you load a model, change the settings, check the "Save experiment annotation inside model" box but not the "Simulate" box then run the simulation it does indeed run the simulation with those settings.

However, if you then go back into the setup box, change the settings again with the same boxes checked and click OK then when you run another simulation you find it's using the first settings not what you just changed it to. Likewise when you open the setup dialog, change them, click OK to save them and open the dialog box again your changes have gone, it's back to the original settings.

in reply to:  5 ; comment:6 by Francesco Casella, 5 years ago

Milestone: 2.0.01.16.0
Resolution: fixed
Status: closedreopened

Replying to timswait@…:

Also the simulation setup options don't seem to stick if you change them after you've run a simulation. If you load a model, change the settings, check the "Save experiment annotation inside model" box but not the "Simulate" box then run the simulation it does indeed run the simulation with those settings.

However, if you then go back into the setup box, change the settings again with the same boxes checked and click OK then when you run another simulation you find it's using the first settings not what you just changed it to.

Oops, you're right. This is not as it should be. We'll see if we can fix this for the forthcoming 1.16.0 release.

Likewise when you open the setup dialog, change them, click OK to save them and open the dialog box again your changes have gone, it's back to the original settings.

Ditto.

@adeas31, is this a bug or a feature? I'm leaning towards a bug, but I'm not 100% sure

in reply to:  4 comment:7 by Francesco Casella, 5 years ago

Replying to timswait@…:

Thank you for taking the time to respond

Thank you for reporting your issues!

We need more end user's feedback, particularly from inexperience users, which may get frustrated early on by weird behaviour and thus abandon the tool.

in reply to:  3 ; comment:8 by Adeel Asghar, 5 years ago

Replying to casella:

Replying to anonymous:

-It would make sense to make the default UI follow the typical workflow, either left to right or top to bottom. My expected workflow for a simulation would normally be: Set up model -> Check model -> Set up simulation parameters -> Run Simulation -> View results
In most respects the default toolbar along the top follows this, you have the viewing and shapes toolbars that are used in creating the model, then the Check toolbar, but then when you come to the simulation toolbar, the simulate buttons are before the settings button, which to me seems the wrong way round. I think the Setup button should be first.

I guess the underlying idea is that existing model with saved simulation options can be simulated right away without setup, which is a kind of optional feature. Also Dymola (our main competitor) has the setup button to the right of the simulate button, maybe that also nudged us towards this setup. But you may have a point here.

-Having it default to run the simulation when you click on "OK" in the setup box is confusing.

I definitely agree with that. I've been using OMEdit for some time now, but I'm always a bit taken aback when the simulation processs starts right away as I end the setup.

@adeas31, I would change the default setting to not simulate right away.

I don't agree with that. I personally will get annoyed if I have to hit an extra button just to run the simulation every time I change the settings and I m sure there are many others who think the same. I mean from the setup window I want just one button to apply my settings and run the simulation. I think most of this confusion came because the user didn't notice the simulate checkbox in the setup window. He can even start the simulation with animation directly from there.

I'd expect to enter the simualation settings and then run the simulation I want (I'm a simple engineer so I choose the simulate with animation option!) I didn't notice the checkbox for simulate in the setup dialog (simple engineers don't always read as much they should!) so I was clicking OK on the setup dialog, then clicking Simulate with Animation (almost) immediately. This resulted in seemingly random crashes and much swearing!

You definitely have a point here as well. As I wrote in comment:1,I'm still a bit worried about the possibility of OMEdit ending in a locked state if something goes wrong with the initialization. But I guess we could at least grey out those buttons during the translation and C code compilation phase. That is unlikely not to return properly, and if it does, then OMEdit crashes anyway, while a low-level failure of the simulation executable doesn't cause OMEdit to crash.

@adeas31, do you think this is doable?

Yes this is doable but I will target it for next release. When you click on simulate following things happens,

  1. translateModel is called which translates the model and creates the model files necessary for simulation. This step is synchronous. The user can't interact with the GUI during this process.
  2. OMEdit starts compiling the files to generate the simulation executable. This is asynchronous process.
  3. OMEdit runs the simulation executable. This is also asynchronous.

The problem is if step 2 takes a long time then user could in the meantime change the simulation settings and can run step 1 which will regenerate the model files and the compilation of step 2 end up in bad state.

The good news is OMEdit has boolean flags to check both step 2 and 3 if they are running or not. We could restrict the step 1 if step 2 and 3 are running.

Greying out the simulate buttons when one is running would be good, or some other way to indicate in the main window that a simulation is running. If you've already run a simulation and have hidden the pop up window behind the main one then it doesn't pop back in front so you have no way of knowing one is going on.

We should definitely bring it back to front every time we simulate, @adeas31 what do you think?

This is the case right now. Every time you run the simulation the GUI brings back the output window to front. Note that each simulation run has its own output window.

Also, it might be neat to have three buttons instead of two on the setup window. So instead of "OK" (which is a bit ambiguous) and "Cancel" then how about "Simulate" (maybe add some checkboxes for with debugger, with animation etc), "Save Settings" (again some checkboxes for the options) and "Cancel.

I'm not sure, the possible number of combinations is quite large, and I don't like much the idea of duplication of commands in different places. Maybe the current setup is good enough without the default Simulate selection?

The current setup is good enough with the default Simulate selection.

in reply to:  6 comment:9 by Adeel Asghar, 5 years ago

Replying to casella:

Replying to timswait@…:

Also the simulation setup options don't seem to stick if you change them after you've run a simulation. If you load a model, change the settings, check the "Save experiment annotation inside model" box but not the "Simulate" box then run the simulation it does indeed run the simulation with those settings.

However, if you then go back into the setup box, change the settings again with the same boxes checked and click OK then when you run another simulation you find it's using the first settings not what you just changed it to.

Oops, you're right. This is not as it should be. We'll see if we can fix this for the forthcoming 1.16.0 release.

Likewise when you open the setup dialog, change them, click OK to save them and open the dialog box again your changes have gone, it's back to the original settings.

Ditto.

@adeas31, is this a bug or a feature? I'm leaning towards a bug, but I'm not 100% sure

Seems like you are working with different models. Note that each model has its own settings. So if you set some settings for model A and then you switch to model B the simulation setup box will show default settings instead of the settings saved for A.

comment:10 by Francesco Casella, 5 years ago

I mostly agree with comment:8

Regarding comment:9, I just made a test with the following stupid model

model Test
  Real x(start = 0, fixed = true);
equation
  der(x) = 1;
end Test;

and it seems that the behaviour reported by @timswait is indeed taking place. I'm using the latest nightly build. Can you please check?

comment:11 by Adeel Asghar, 5 years ago

Anything specific you changed in setup window that is not preserved?

in reply to:  8 comment:12 by timswait@…, 5 years ago

Greying out the simulate buttons when one is running would be good, or some other way to indicate in the main window that a simulation is running. If you've already run a simulation and have hidden the pop up window behind the main one then it doesn't pop back in front so you have no way of knowing one is going on.

We should definitely bring it back to front every time we simulate, @adeas31 what do you think?

This is the case right now. Every time you run the simulation the GUI brings back the output window to front. Note that each simulation run has its own output window.

If you click on one of the simulate (arrow) buttons then it does indeed bring the pop up simulation window to the front. However if you click on "OK" in the setup dialog with the simulate checkbox ticked it doesn't bring the popup to the front. For me it doesn't open up a new pop up for each simulation run. If you don't close the pop up window from the last simulation then when you run another simulation it takes place in the window that's already open.

On the not being able to change settings:
Mine definitely is acting in the way I described (even with only one model open), If I try to change the simulation settings after having run a simulation it keeps changing them back. The only workaround I've found is to close and open OMEdit or to check the simulate button, click OK, wait for it to run that simulation (which somehow seems to make the settings stick) and then run the simulation with the animation.

in reply to:  11 comment:13 by Francesco Casella, 5 years ago

Replying to adeas31:

Anything specific you changed in setup window that is not preserved?

StopTime for sure. I havent made a thorough review of all other parameters

comment:14 by Francesco Casella, 4 years ago

Milestone: 1.16.01.17.0

Retargeted to 1.17.0 after 1.16.0 release

comment:15 by Francesco Casella, 4 years ago

Milestone: 1.17.01.18.0

Rescheduled to 1.18.0

comment:16 by Adeel Asghar, 4 years ago

PR#7282 fixes this issue by not allowing the user to run the second simulation of the same model until the first one is not finished.

The simulation output is integrated in the Messages Browser and no longer a separate window so this gives more better view to the user.

@casella I tried your test model. I opened the simulation setup window, changed the stop time to 5, simulated the model with new stop time, re-opened the simulation setup window and the stop time is 5.

comment:17 by Francesco Casella, 3 years ago

Milestone: 1.18.0

Ticket retargeted after milestone closed

comment:18 by Francesco Casella, 3 years ago

Milestone: 1.19.0

1.18.0 blocker tickets moved to 1.19.0

Note: See TracTickets for help on using tickets.