default configuration for pre/post optimization modules

[lochel]

omc +help=preOptModules displays all available pre-optimisation modules. To take advantage of this feature, it is completely necessary to dump the default configuration. Otherwise, it is hopeless to figure out a working configuration.

It's the same for post-optimization of course.

[sjoelund.se]

It would also be useful if it was possible to do -preOptModules-=xyz to simply remove xyz from the list of pre-optimizations. Or -preOptModules+=xyz to append xyz to the list of optimizations. Because this would work even if the default changes.

[lochel]

Ordering is essential, so it is not enough to just append the default configuration. But it would be good to have an easy to use option to disable a given module as you proposed.

[lochel]

I added already the default values for preOptModules, postOptModules and initOptModules to the documentation/help page.

[casella]

Just noticed that, see:

​https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html

[lochel]

Replying to casella:

Just noticed that, see:

​https://openmodelica.org/doc/OpenModelicaUsersGuide/latest/omchelptext.html

Yes, it is also available using omc +help=optmodules.

[lochel]

Replying to sjoelund.se:

It would also be useful if it was possible to do -preOptModules-=xyz to simply remove xyz from the list of pre-optimizations. Or -preOptModules+=xyz to append xyz to the list of optimizations. Because this would work even if the default changes.

I will add the functionality to easily enable/disable a specific pre-/post-optimization module.

[lochel]

Replying to lochel:

I will add the functionality to easily enable/disable a specific pre-/post-optimization module.

This ​pull request introduces a couple of new flags:

--forceRecommendedOrdering: This is a Boolean flag with default true. This flag means that the specified pre-/post-/init-optimization modules will be automatically arranged in the recommended order. This flag can be set to false to achieve the old behaviour.

--preOptModules+=module1,module2 / -–preOptModules-=module3,module4 : This activates/deactivates certain pre-optimization modules. Since the back end takes care of arranging all pre-optimization module properly, this cannot be used in combination with --forceRecommendedOrdering=false.
The same is implemented for post-/init-optimization phase. Therefore, the flags are called --postOptModules+=module1,module2 / -–postOptModules-=module3,module4 and --initOptModules+=module1,module2 / -–initOptModules-=module3,module4.

[lochel]

I am not that happy with the name forceRecommendedOrdering. It would be good to have a better name before the next release. However, I will push the changes now. If one has a proposal for a better name, then we could just change it.

[adrpo]

applyRecommendedOrdering or applyDefaultOrdering

[lochel]

Replying to adrpo:

applyRecommendedOrdering or applyDefaultOrdering

Thanks Adrian. More suggestions are still welcome. We can decide on the next OSMC Dev meeting how to finally call this.

---

Should the combination --preOptModules+=something –preOptModules-=something
a) trigger an error and abort translation or
b) trigger a warning which state that this is weird, disable (or enable?) something and continue translation?

[casella]

Replying to lochel:

Replying to adrpo:

applyRecommendedOrdering or applyDefaultOrdering

Thanks Adrian. More suggestions are still welcome. We can decide on the next OSMC Dev meeting how to finally call this.

The problem with these flag names is that it is not clear whose ordering they refer to.

What about --defaultOptModulesOrdering?

Should the combination --preOptModules+=something –preOptModules-=something
a) trigger an error and abort translation or
b) trigger a warning which state that this is weird, disable (or enable?) something and continue translation?

For me it should be an error. If a good soldier receives contradictory orders, it is none of his business to decide which one is the right one. Just stop and wait for new orders.

[sjoelund.se]

Replying to casella:

For me it should be an error. If a good soldier receives contradictory orders, it is none of his business to decide which one is the right one. Just stop and wait for new orders.

No. Latest orders are the ones you accept. Because they may have changed:

-d=gen,nogen

Simply means, set gen, then unset it. No problem.

--preOptModules+=something --preOptModules-=something

Means add something, remove something. No problem.

[casella]

Replying to sjoelund.se:

Replying to casella:
No. Latest orders are the ones you accept. Because they may have changed:

I have to admit I was exempted from military service back then. So I'm not really qualified here :)

Seriously, I agree with your point.

[lochel]

Replying to sjoelund.se:

No. Latest orders are the ones you accept. Because they may have changed:

Okay, now I have implemented it that way (see ​PR291).

[sjoelund.se]

Milestone renamed

[sjoelund.se]

Milestone renamed