id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
5926	Save a proper result file when interrupting a simulation	Francesco Casella	Lennart Ochel	"Everybody's happy when a simulation terminates successfully: you look at the results and then either they are good for you, or if they are not you can figure out what's wrong, change something, and re-simulate.

However, there are many cases in which simulations get stuck, because of chattering or any other reason. This happens all the time in real life. After some time, you just need to kill the simulation process. Unfortunately, when you do so the process does not die gracefully as it should, and in particular ''no valid simulation results are saved'' up to that point, which makes it real hard to figure out what's wrong and apply suitable remedies.

This is a MWE of such a situation:
{{{
model Chattering
  Real x(start = 1, fixed = true);
equation
  der(x) = noEvent(if x > 0 then -1 else 1);
annotation(experiment(StopTime = 2));
end Chattering;
}}}
If you simulate it in OMEdit, the simulation gets stuck indefinitely at 50% of the simulation time span. When you finally hit the Cancel Simulation button you get
{{{
Process crashed
Simulation process failed. Exited with code 62097.
}}}
and if you try to check the results in the Variables Browser, you get an error window saying:
{{{
Corrupt file. nvar 0
}}}

I think this behaviour is really not professional. Particularly if it takes place after your precious simulation has been running for half an hour. 

This is what we need to happen in case the Cancel Simulation button is pressed:
- A terminate signal is sent to the simulation executable
- The simulation executable stops doing whatever it is doing, saves the simulation results obtained so far, and terminates with an error message like: ""Simulation stopped by the user at time = <current_time>"". 
- The simulation results from StartTime to current_time are loaded in the Variables Browser.

I guess this requires updates to OMEdit as well as to the runtime. I would assign this provisionally to @adeas31, please coordinate with @karim, @AnHeuermann, @mahge930 and @niklwors to come up with a working solution. @sjoelund.se may also be interested, since this has connections with the debugger.

I think this is really a must-have for 2.0.0. It would be nice to have it in 1.16.0 already."	defect	new	blocker	2.0.0	Run-time				Karim Adbdelhak Andreas Heuermann Niklas Worschech Mahder Alemseged Gebremedhin Andrea Bartolini Martin Sjölund