Opened 7 years ago
Last modified 7 years ago
#4609 new enhancement
Refresh button
Reported by: | Lennart Ochel | Owned by: | Adeel Asghar |
---|---|---|---|
Priority: | high | Milestone: | Future |
Component: | OMPlot | Version: | |
Keywords: | Cc: |
Description
A reload button would improve the usage of OMPlot (and probably OMEdit as well) in certain cases:
- Plotting simulation results while the simulation is still running
- Updating the plot view (and keeping all settings, e.g. scaling and selected set of variables) after recreating the result file (e.g. with different parameters)
- ...
Change History (3)
comment:1 by , 7 years ago
follow-up: 3 comment:2 by , 7 years ago
I think there are two different scenarios to consider: Dealing with result files without any knowledge about connected simulations (plain OMPlot) and an embedded plotting experience in OMEdit.
comment:3 by , 7 years ago
Replying to lochel:
I think there are two different scenarios to consider: Dealing with result files without any knowledge about connected simulations (plain OMPlot) and an embedded plotting experience in OMEdit.
Absolutely, I was obviously referring to the OMEdit scenario.
I don't think a refresh button is the best idea.
Use case: you are simulating one model, the simulation takes a lot of time (> 30 s), there are many variables to monitor, possibly spread over multiple windows, and you'd like to see what is happeing as the simulation time increases, to stop the simulation if neecessary and avoid wasting time to wait until the end if something goes wrong. Possibly, variables from other .mat files could be open in the same windows, and they should stay untouched.
There is one and only one .mat file being written, the tool knows where it is. I would suggest that every X_r seconds we poll the file size from the file system, and if it has increased, then the plots are updated automatically. X_r must be chosen to avoid choking the system on one hand, and to avoid too large delays on the other hand, so probably something like 2-5 seconds. Alternatively, we could use stuff stored in memory. This is irrelevant from an end-user point of view, what is important is the ability of seeing the simultation results as the computation is progressing, without the need of doing anything.
As long as we use less than 100% computing power of one CPU to do this on a multi-core machine, there will be no performance penalty, as the simulation typically runs on a single thread as of today, and the update will be done on a different core.
Of course, if it is found that more than X_r seconds are taken to refresh the result, the whole thing should not hang but rather X_r should be multiplied by a factor of 1.5 of something like that.