Opened 4 years ago
Last modified 3 years ago
#6062 new enhancement
Proper handling of changed global settings
| Reported by: | Oliver Lenord | Owned by: | Adeel Asghar |
|---|---|---|---|
| Priority: | high | Milestone: | |
| Component: | OMEdit | Version: | v1.16.0-dev |
| Keywords: | compiler flags | Cc: |
Description (last modified by )
As reported in https://trac.openmodelica.org/OpenModelica/ticket/6059 and https://trac.openmodelica.org/OpenModelica/ticket/6061 it is unexpected that changes to the settings, e.g. compiler flags, are not carried over to the simulation unless OMEdit is restarted.
The dialog box has a disclaimer saying: "Global flags applied to the Simulation Setup dialog upon the first simulation of a model."
In other words once a model has been simulated the only way to apply changes to the settings is through the "Simulation Setup" dialog.
None of the following helps to update the local settings:
- Simulate
- Re-simulate
- Re-simulate Setup (at least this should work)
- Unload+reload+simulate
- Delete results+simulate
Only a restart of OMEdit will carry over the global settings to the new simulation.
As this behavior is at least partially unexpected it can cause a significant amount of frustration when trying out different compiler flags.
I suggest that when a model is re-compiled, then it should also appreciate the latest global settings.
Change History (11)
comment:1 by , 4 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 4 years ago
| Milestone: | Future → 1.17.0 |
|---|---|
| Priority: | normal → high |
follow-up: 4 comment:3 by , 4 years ago
Nothing against having local setting for compiler flags.
My point is that changes to global settings are expected to have global impact. Ignoring this change for the entire session is not intuitive.
About the re-simulate setup: What surprised me that the added flag was not preserved.
comment:4 by , 4 years ago
Replying to olivleno:
My point is that changes to global settings are expected to have global impact. Ignoring this change for the entire session is not intuitive.
I agree. I think we should pass the changes to the global settings to the open sessions.
About the re-simulate setup: What surprised me that the added flag was not preserved.
Can you post a MWE to reproduce the issue?
follow-up: 7 comment:5 by , 4 years ago
Ok, I have to correct myself. After re-simulate the added flag is still there when opening the re-simulate setup again.
But after going back to the modeling view and hitting simulate, the model is recompiled and the additional flag is gone.
My expectation would be:
- Local settings should be derived from the global settings.
- Modified local settings should be preserved.
- Modified global settings should overrule local settings, assuming that a merge is not easily possible. Nice to have would be a warning after ok, before closing of global settings dialog in case that local flags would be overruled.
The assumption is that global settings are expected to always take affect. And they are typically applied for general things. The overruling should therefore be a rather rare case.
comment:6 by , 4 years ago
To ease understanding of the parallelism between local and global options, maybe in the Options dialog the name could be "Translation and Simulation" instead of just "Simulation"?
It seems to me that it refers to what locally are both translation and simulation flags.
comment:7 by , 4 years ago
Replying to olivleno:
Ok, I have to correct myself. After re-simulate the added flag is still there when opening the re-simulate setup again.
But after going back to the modeling view and hitting simulate, the model is recompiled and the additional flag is gone.
Of course this shouldn't happen.
My expectation would be:
- Local settings should be derived from the global settings.
- Modified local settings should be preserved.
- Modified global settings should overrule local settings, assuming that a merge is not easily possible. Nice to have would be a warning after ok, before closing of global settings dialog in case that local flags would be overruled.
The assumption is that global settings are expected to always take affect. And they are typically applied for general things. The overruling should therefore be a rather rare case.
Sounds reasonable. We'll try to look at this in September
follow-up: 9 comment:8 by , 4 years ago
Is this really an enhancement. As far as I remember, it worked in previous versions of OMEdit!?
comment:9 by , 4 years ago
Replying to rfranke:
Is this really an enhancement. As far as I remember, it worked in previous versions of OMEdit!?
It worked, if you only had one model open. If you were working with multiple models open in the same session, requiring different setups, it didn't.
comment:10 by , 4 years ago
| Milestone: | 1.17.0 → 1.18.0 |
|---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
@olivleno, this was discussed with @adeas31 some time ago, the discussion is reported in #5329, #5569, and PR #333. Please review that.
This is not necessarily a good idea in all cases.
Imagine that you are working on a complicated model with special needs, which requires to set three different flags to get it to work properly, plus other three flags for logging and diagnostics while you're figuring out what's wrong.
Of course you don't want to set them as global flags in Tools|Options, because they will affect every other model you are going to simulate forever. This is particularly dangerous for runtime flags such as
LOG_NLS_V, which can generate a ton of output and potentially hang OMEdit for quite a while.On the other hand, if you are developing the model at the source code level, every time you apply a change you need to re-compile, and then you'd need to re-set those three+three flags from scratch each time.
I actually found myself in this situation once, and I needed to set those six flags in three different tabs of the Simulation Setup each time, which was extremely annoying, besides being error-prone. So, we changed the behaviour so that flags that are changed locally in Simulation Flags are retained for the entire session, but then reset to default when a new session is run. This seems a very natural and sensible compromise: it avoids re-setting the flags every time during the session, which makes you feel very stupid, while avoiding long-term settings that you may forget about when you restart a session after some time.
It is true that people normally don't read the fine print and that a good GUI should be intuitive and not require to do that. Maybe a good compromise could be that if you change the global options, this also affects the local settings of the last simulated model.
What do you think?
That's by design, see above
This should indeed work, but only for simulation (i.e. runtime) flags. Of course it doesn't work for Translation flags, which only affect compilation, since you are explicitly avoiding the recompilation with Re-simulate. Given the keywords you gave to this ticket, I guess this is why it doesnt' work in your case, which is also consistent with the expected behaviour.