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 Oliver Lenord)

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 Oliver Lenord, 4 years ago

Description: modified (diff)

comment:2 by Francesco Casella, 4 years ago

Milestone: Future1.17.0
Priority: normalhigh

@olivleno, this was discussed with @adeas31 some time ago, the discussion is reported in #5329, #5569, and PR #333. Please review that.

I suggest that when a model is re-compiled, then it should also appreciate the latest global settings

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?

None of the following helps to update the local settings:

  • Simulate
  • Re-simulate
  • Unload+reload+simulate
  • Delete results+simulate

That's by design, see above

  • Re-simulate Setup (at least this should work)

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.

comment:3 by Oliver Lenord, 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.

in reply to:  3 comment:4 by Francesco Casella, 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?

comment:5 by Oliver Lenord, 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 massimo ceraolo, 4 years ago

COMMENT DELETED

Last edited 4 years ago by massimo ceraolo (previous) (diff)

in reply to:  5 comment:7 by Francesco Casella, 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

comment:8 by Rüdiger Franke, 4 years ago

Is this really an enhancement. As far as I remember, it worked in previous versions of OMEdit!?

in reply to:  8 comment:9 by Francesco Casella, 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 Francesco Casella, 4 years ago

Milestone: 1.17.01.18.0

Retargeted to 1.18.0 because of 1.17.0 timed release.

comment:11 by Francesco Casella, 3 years ago

Milestone: 1.18.0

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.