OMEdit keeps command line options between runs

[massimo ceraolo]

Consider the package TestOptAnn.
1) Run RL: this is a time simulation and runs OK
2) run BangBang: this is a dynamic optimisation run and runs ok. Dynamic optimisation is selected through the usage of the following annotations:

       __OpenModelica_commandLineOptions="+gDynOpt",
       __OpenModelica_simulationFlags(optimizerNP = "1", s = "optimization"));

3) run RL again: it fails and says:

assert | debug | <p>The model was not compiled with -g=Optimica and the corresponding goal function. The optimization solver cannot be used.</p>

I suppose failing is due to OMEdit keeping +gDynOpt between 2) and 3). I don't think this is correct, since this is an annotation option.

[Adeel Asghar]

Its not the command line options that OMEdit keeps between runs. But OMEdit do remember the simulation flags between run. Since TestOptAnn.RL didn't mention any solver so the default one is used but TestOptAnn.BangBand changes the solver to optimization so when you run TestOptAnn.RL again then the solver optimization is used.

One idea is to always clear the simulation options and sets everything to default before running the new simulation. However, it might not be optimal in few cases.

[Francesco Casella]

Replying to adeas31:

One idea is to always clear the simulation options and sets everything to default before running the new simulation. However, it might not be optimal in few cases.

Please don't do that, if you are trying out the effects of different combined options, re-setting all of them each time with the GUI (possibly in widely different places) would be a nightmare.

On the other hand, I agree with @ceraolo that the reported behaviour is confusing.

From an end-user perspective, the ideal situation would be that OMC remembers the simulation flags separately for each different model. This requires keeping a list of the models that have been run in a session, each with its own flags. Would that be difficult to implement?

[Adeel Asghar]

Of course remembering the flags used for each model requires some implementation work but I am afraid that it will not solve the problem. For instance if we just consider the above example, instead of simulating TestOptAnn.RL, first simulate TestOptAnn.BangBang first and then after it when you simulate TestOptAnn.RL you will get a same error because there is no simulation flags defined in the model and OMEdit doesn't have any flags in its history for that model.

[massimo ceraolo]

I suppose that an "autoreset flag" option that implements the solution in comment 1 would do the job. If some wants to play with different options without writing code he just uses autoreset flag unchecked.
When this option is checked, one knows that priority is first on default options, then on those written in the code.
@adeas31 @casella, what to you think?

This would be helpful also for simulation tine, that now is held between runs of different models, which is suboptimal.

[Adeel Asghar]

I am fine with an autoreset option/flag.

[Francesco Casella]

Replying to ceraolo:

I suppose that an "autoreset flag" option that implements the solution in comment 1 would do the job. If some wants to play with different options without writing code he just uses autoreset flag unchecked.
When this option is checked, one knows that priority is first on default options, then on those written in the code.
@adeas31 @casella, what to you think?

Fine for me except I don't understand "priority is first on default options, then on those written in the code". Shouldn't it be the other way round? If there are some special settings in the code, they were putting there precisely to alter the settings w.r.t. the default.

From what I understand there is a default OMEdit simulation setting (which should be declared somewhere). Then you can change it with the Simulation setup window and/or with the __OpenModelica_simulationFlags annotation. From what I understand, you should first apply the defaults, then override them with the annotation, and finally override them with whatever modifications w.r.t. the default was applied to the Simulation setup window. Do I miss something?

[massimo ceraolo]

Fine for me except I don't understand "priority is first on default options, then on those written in the code". Shouldn't it be the other way round? If there are some special settings in the code, they were putting there precisely to alter the settings w.r.t. the default.

Sure! my fault. I should have said that OMEdit first applies default options, then those from __OpenModelica_simulationFlags

From what I understand there is a default OMEdit simulation setting (which should be declared somewhere). Then you can change it with the Simulation setup window and/or with the __OpenModelica_simulationFlags annotation. From what I understand, you should first apply the defaults, then override them with the annotation, and finally override them with whatever modifications w.r.t. the default was applied to the Simulation setup window. Do I miss something?

Just thinking. If we decide to use these three levels of access to options, probably we won't need the autoreset option/flag anymore, isn't it?

I mean, a user that wants to change options repeatedly (see comment 2) could easily play on them through the Simulation Setup window, thus overriding program defaults and __OpenModelica_simulationFlags
On the other hand, the user of this ticket's description (that wants to use different options for different models without the burden of changing simulation setup options) could do his job using __OpenModelica_simulationFlags.

It seems to me that this is the simpler and most effective solution to our problem.

There might a remaining issue. OMEdit, if Preserve User's GUI Customizations is checked, keeps OMFlags between two consecutive sessions. Is still correct in this ticket's framework? The three levels of access to options that Francesco envisaged, and seem so effective, probably are at their best if when OMEdit starts with the OMC flags field empty, so that the defaults are always the same. This also has other advantages: it eases repeating behaviours across computers.

To resume my proposal:
1) implement the three three levels of access to options proposed by Francesco in comment 6
2) not add any autoreset option/flag
3) always start OMEdit with Simulation setup OMC Flags empty, whatever the state of Preserve User's GUI Customizations checkbox
But first, again, I need your opinion!

[massimo ceraolo]

@casella, would you mind telling your opinion on comment 7?
Maybe we are near to give the right directions to implement a solution to this ticket.

[Francesco Casella]

@ceraolo, we discussed this yesterday at the devmeeting. The agreement was to implement your autoreset idea for the time being (which is easier), and then consider my proposal for the next release, possibly with some more end-user input.

[massimo ceraolo]

Thanks a lot for the info

[Adeel Asghar]

Instead of implementing the autoreset flag. I have implemented the solution proposed by Francesco and on which we agreed during the devmeeting.
In 857e886/OMEdit I fixed the handling of simulation options in the following way.

• Each class has its own simulation options.
• Start with the default simulation options.
• If the class has experiment and __OpenModelica_simulationFlags annotation then apply them.
• After that all the changes made via Simulation Setup are stored inside OMEdit for each class.

I am keeping this ticket open. We need to test this well enough before the release. I will wait for your feedback.

[massimo ceraolo]

I will check tomorrow and let you know.

[Adeel Asghar]

Yes. We always start with default simulation options regardless of Preserve User's GUI Customizations.

[massimo ceraolo]

I found an issue with StopTime.

I created two models RL1 and RL2 identical to RL of this ticket's package TestOptAnn. In both of them I removed StopTime from the experiment annotation.
1) simulate RL1: one second is simulated
2) open RL2 and set stopTime=2s using Simulation Setup button.
3) simulate RL2. Two seconds are simulated
4) re-simulate several times: simulation time toggles between 1s and 2s

NEWLY EDITED COMMENT TO ENHANCE THE ISSUE DESCRIPTION
@adeas, please tell me if you can reproduce it.

Well, I eventually found that this comment's issue is not related to this ticket, but I think it is better to add details here. It is an issue related to plot window display.

Software framework:
note that I made my tests with

OMEdit 1.13.0~dev-137-g0e9c2ff Connected to OpenModelica 1.13.0~dev-1195-g6d891ea
on Ubuntu 16.04

I also used as Options.Plotting "SubWindow view"

Steps to reproduce:
0) create two models RL1 and RL2 identical to RL of this ticket's package TestOptAnn. In both of them remove StopTime from the experiment annotation.
1) start OmEdit and load RL1 and RL2.
2) simulate RL1, open a full-screen plot window, and look at inductor1.i: one-second plot is displayed
3) open RL2 and set stopTime=2s using Simulation Setup button, click ok (with the Simulate check-box checked).
4) open a new plot window, and in it look at inductor1.i (from RL2 ouput). A two-second plot is displayed
5) re-simulate several times: apparently the horizontal axis of inductor.i toggles between 1s and 2s. In reality, what happens is that the output toggles between Plot:1 and Plot:2. So simulations are correct, what is misleading is just this unjustified plot toggle.

Should I open a separate ticket for this?

[Adeel Asghar]

4) re-simulate several times: simulation time toggles between 1s and 2s

Please see updated description in comment 14

[Francesco Casella]

Replying to adeas31:

Instead of implementing the autoreset flag. I have implemented the solution proposed by Francesco and on which we agreed during the devmeeting.
In 857e886/OMEdit I fixed the handling of simulation options in the following way.

• Each class has its own simulation options.
• Start with the default simulation options.
• If the class has experiment and __OpenModelica_simulationFlags annotation then apply them.
• After that all the changes made via Simulation Setup are stored inside OMEdit for each class.

If this works as expected, it's very good for me.

Regarding Preserve User's GUI customization, I agree with comment:13 that thisn should not change the base defaults, but that any preserved customizations are always counted as last minute changes to Simulation Setup, thus overriding all other settings. The setup process (see comment:11) is actually a state machine, and the initial state (i.e., the default options) should be the same for all users and should not be customizable, otherwise we end up in a big mess.

I would state what the default options are explicitly in the User's Guide, as well as how this mechanism works. The idea is that the mechanism should be intuitive (and I think it is) but it should also be explained if one really needs to exploit it without surprises.

I only see a potential problem: if we change the default options in the future, we may cause some problems to existing models, because the initial state of the setup state machine changes. However, this is also probably the best compromise. For example, at some point (see #4990) we should bid farewell to the good old dassl solver as a default, and switch to ida, which has the same roots but is still actively maintained and improved, so it is expected to work better in general.

In this case, the intent is that users that did not specify a specific solver different from the default in their models don't stick to dassl but end up using the new default ida, in general there's no point at having models built prior to 2018 to drag along with the old solver. Of course this may cause some problem in some corner cases, but I guess we have to live with it. It goes without saying that we should advertise these changes widely in the release notes.

[massimo ceraolo]

Replying to adeas31:

4) re-simulate several times: simulation time toggles between 1s and 2s

You mean re-simulate RL2 or re-simulate both RL1 and RL2.

Re-simulate always RL2

[massimo ceraolo]

Regarding Preserve User's GUI customization, I agree with comment:13

Also agree. This implies always starting OMEdit with some fields in Tools|Options|Simulation (at least OMC flags) and some (or all?) fields in Simulation Setup|Simulation flags blank whenever OMEdit is started. See point 3 in comment 7.

[Adeel Asghar]

Note that ​OMC Flags and ​simulation flags are two different things.

[massimo ceraolo]

Replying to adeas31:

Note that ​OMC Flags and ​simulation flags are two different things.

.

My ticket description involved __OpenModelica_commandLineOptions whose values go into "OMC Flags", and __OpenModelica_simulationFlags, which go into Simulation Setup|Simulation flags.

In think that

1) the introduced three-level of priorities (i.e. the state machine discussed by @casella) should involve all parameters that can be set using __OpenModelica_commandLineOptions,
__OpenModelica_simulationFlags, and annotation experiment (maybe some more?)

2) I think that using two different names for the same thing (__commandLineOptions and OMC Flags) is misleading, and this nomenclature should be made more uniform

3) once it is really clear which settings are subject to the "flag state machine" (as per comment #16) they should be clearly recognised from within Tools|Options and "Simulation Setup" windows. I don't know how to do this graphically. Maybe this would involve some option reordering.

[Adeel Asghar]

Well I don't think we need to do the same for __OpenModelica_commandLineOptions and OMC Flags since you can't set them via Simulation Setup window.

__OpenModelica_commandLineOptions are used when translating the model and generating the files needed for the simulation. There are two ways to set the compiler flags,

• Tools > Options > Simulation > OMC Flags. These flags are directly applied to the compiler and will stay for the whole session and future sessions.
• __OpenModelica_commandLineOptions annotation flags are only applied when translating a model which contains them. They are set before the translation and are removed after the translation.

Now I am not sure if the above behavior is giving you some problem OR if you want to improve the way compiler flags are handled. Although I do agree that we should have same name so I can rename OMC Flags to OMC Command Line Options. What do you think?

[massimo ceraolo]

What do you think?

First of all I must say that your implementation is perfect for my present needs. I just take the opportunity to contribute also thinking to other users.

According to comment 6 priority rule:
1) flags have a general default
2) then annotations are applied (for each class)
3) then values in the Simulation|Setup window are applied (and stay stable for each class, in the same OMEdit session)

From your comment 21 I understand that only parameters in the Simulation Setup window are affected by this rule. Am I right?
In case the answer is yes, I'm ok with this choice.
In case it is no, maybe some clear way to show the user which Simulation setup window flag follows it and which does not should be found.

From your comment 21 I also understand that OMC flags (or, better, OMC Command Line Options) do not follow the 3-level above priority rule. I'm also ok with this choice.

[Adeel Asghar]

From your comment 21 I understand that only parameters in the Simulation Setup window are affected by this rule. Am I right?

Yes. I have also wrote a bit of documentation about it in the users guide.

It seems like I can safely close this ticket now.

I have already updated the OMC Flags to OMC Command Line Options for the sake of consistency.

[Francesco Casella]

Replying to adeas31:

From your comment 21 I understand that only parameters in the Simulation Setup window are affected by this rule. Am I right?

Yes. I have also wrote a bit of documentation about it in the users guide.

In fact, I also had the OMC Command Line Options in mind when talking about the flag state machine, but I'm fine with the current status, i.e., only simulation flags are considered.

It seems like I can safely close this ticket now.

Agreed.

I have already updated the OMC Flags to OMC Command Line Options for the sake of consistency.

I also like this.