modelica / ModelicaSpecification

Specification of the Modelica Language
https://specification.modelica.org
Other
95 stars 41 forks source link

Suppress warning for parameters with fixed = true, explicitly set start attribute, no binding, and annotation(Dialog(enable = false)) #3504

Open casella opened 3 weeks ago

casella commented 3 weeks ago

Description of the problem

As discussed here by @AntoineGautier there are some application cases, where there are parameters that are propagated to conditional components, that are activated by some Boolean parameters. When the conditional components are not active, those parameters are not needed, but when they are, they need to be provided explicitly.

Adding a default value to them is not a good idea, because then you don't get any warning if you don't give them a value when the corresponding components are activated. On the other hand, if there is no default value, the model cannot be compiled when they are not needed (and thus not set), because some parameters lack binding equations.

The current workaround is to give them a start attribute only, which prevents the compilation error when they are not needed, and gives a warning when they are not set, according to Section 8.6

If a parameter has a modifier for the start attribute, does not have fixed = false, and neither has a binding equation nor is part of a record having a binding equation, the modifier for the start attribute can be used to add a parameter binding equation assigning the parameter to that start value. In this case a diagnostic message is recommended in a simulation model.

[This is used in libraries to give rudimentary defaults so that users can quickly combine models and simulate without setting parameters; but still easily find the parameters that should be set properly.]

Unfortunately, this gets you a warning also in those cases where the components are not activated, so these parameters do not need to be set. This is quite annoying, particularly in the case that the parameter dialogs are not enabled, so it is actually not possible to give those parameter a value through the GUI

Proposal

This issue can be solved easily by suppressing the warning when the parameter dialog is not enabled

If a parameter has a modifier for the start attribute, does not have fixed = false, and neither has a binding equation nor is part of a record having a binding equation, the modifier for the start attribute can be used to add a parameter binding equation assigning the parameter to that start value. In this case a diagnostic message is recommended in a simulation model, unless the parameter has a Dialog(enable) annotation set to false.

[This is used in libraries to give rudimentary defaults so that users can quickly combine models and simulate without setting parameters; but still easily find the parameters that should be set properly. It can be also used to provide default values for parameters that are propagated to conditionally instantiated components, to manage the case when those components are not instantiated and thus the corresponding parameter input fields are disabled in the GUI.]

This feature is extensively used by the Buildings library (see HVAC and Control Templates for the Modelica Buildings Library), but is also needed for the MSL, e.g. Modelica.Electrical.Machines.BasicMachines.SynchronousMachines.SM_ElectricalExcited

HansOlsson commented 2 weeks ago

I agree with this - and I realized that Dymola has already implemented something close to this based on the same understanding: parameter Real x(start=2) annotation(Dialog(enable=false)); gives the following without any warnings or errors:

Translation of Unnamed The DAE has 0 scalar unknowns and 0 scalar equations. Statistics Selected continuous time states The following parameters have enable=false and don't have any value, only a start value: x(start = 2) Finished

With the proposed change we might disable this listing altogether, but we might also keep it as it gives some benefit.

One could also generalize it to disabled parameters not having a start-value (using fallback value), but I find that too prone to mistakes.

HansOlsson commented 2 weeks ago

Language group: Agree that good idea.